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Chapter 1: About Advanced Networking 



Volume 5: Advanced Networking discusses networking tasks that are not required in 
every environment, such as: 

□ TCP/IP settings. 

□ WAN Optimization, which enables you to optimize environments with application 
delivery networks (ADNs). 

□ Forwarding, which allows you to define the hosts and groups of hosts to which 
client requests can be redirected. 

□ Health Checks, which reports on the health of upstream hosts. 

About This Book 

This book is organized into the following chapters: 

□ Chapter 2: "Configuring an Application Delivery Network" on page 13 

□ Chapter 3: "Attack Detection” on page 53 

□ Chapter 4: "TCP Connection Forwarding" on page 59 

□ Chapter 5: "Bandwidth Management" on page 67 

□ Chapter 6: "Authenticating an SG Appliance" on page 87 

□ Chapter 7: "Configuring Failover" on page 97 

□ Chapter 8: "Configuring the Upstream Network Environment" on page 101 

□ Chapter 9: "Internet Caching Protocol (ICP) Configuration" on page 121 

□ Chapter 10: "Using RIP" on page 127 

□ Chapter 11: "Configuring the SG Appliance as a Session Monitor" on page 133 

□ Chapter 12: "Configuring and Using the SG Client" on page 139 

□ Chapter 13: "SOCKS Gateway Configuration" on page 183 

□ Chapter 14: "Health Checks" on page 199 

□ Chapter 15: "TCP/IP Configuration" on page 233 

□ Chapter 16: "Virtual IP Addresses" on page 237 

□ Chapter 17: "WCCP Settings" on page 239 

□ Appendix A: "Glossary” on page 249 

□ Appendix B: "Using Policy to Manage Forwarding" on page 263 
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Document Conventions 



The following table lists the typographical and Command Line Interface (CLI) syntax 
conventions used in this manual. 

Table 1 -1 . Document Conventions 



Conventions 


Definition 


Italics 


The first use of a new or Blue Coat-proprietary term. 


Courier font 


Command line text that appears on your administrator workstation. 


Courier Italics 


A command line variable that is to be substituted with a literal name or 
value pertaining to the appropriate facet of your network system. 


Courier Boldface 


A Blue Coat literal to be entered as shown. 


II 


One of the parameters enclosed within the braces must be supplied 


[] 


An optional parameter or parameters. 


1 


Either the parameter before or after the pipe character can or must be 
selected, but not both. 
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The Blue Coat implementation of an Application Delivery Network (ADN) requires 
two-sided deployments, with an SG appliance (a peer ) at each end of the WAN link. It 
also features: 

□ Byte caching. The use of byte caching in an application delivery network reduces 
the amount of TCP traffic across a WAN by replacing large chunks of repeated data 
with small tokens representing that data. Working with patterns detected in the 
WAN traffic, the ADN pair of systems handling the traffic builds a byte cache 
dictionary of small tokens. 

□ Acceleration techniques. The use of bandwidth management, compression, 
protocol optimization, and object caching reduces WAN usage even more. 

In such an environment, with only minimal configuration changes, between 30 percent 
and 90 percent of WAN usage can be eliminated, and WAN performance can be 
increased from 30 percent to 90 percent. Applications that benefit from ADN 
optimization include Windows file servers, Web share applications such as WebDAV, 
CRMs such as Siebel, e-mail, and FTP. 




Dictionary Tokens over Encrypted ADN Tunnels 



In addition, you can configure the ADN network to provide additional security to 
internal ADN routing connections and to ADN tunnel connections that carry 
optimized application data. In a fully secured ADN network, only authenticated and 
authorized devices are allowed to join the ADN network. All connections between 
ADN nodes and the ADN manager and connections among the ADN nodes are 
ensured of message authenticity and privacy protection. 
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In this Chapter 

The following topics are discussed in this chapter: 

□ Section A: "About the Blue Coat Implementation for WAN Optimization" on page 15. 

□ Section B: "Basic ADN Setup” on page 21. 

□ Section C: "Transparent and Explicit Connection Deployments" on page 23. 

□ Section D: "Securing the ADN Network" on page 32. 

□ Section E: "ADN Network History, Statistics, and Health Metrics" on page 39. 

□ Section F: "Advanced Tunnel Optimization" on page 42. 

□ Section G: "Manually Re-Sizing a Byte-Cache Dictionary" on page 45. 

□ Section H: "Related CLI Syntax to Configure an ADN Network" on page 48. 

□ Section I: "Policy" on page 50. 
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Section A: About the Blue Coat Implementation for WAN Optimization 



Section A: About the Blue Coat Implementation for WAN Optimization 

This section provides conceptual information regarding various deployments that employ 
WAN optimization. 

Am ADN network is composed of an ADN manager and backup ADN manager, ADN 
nodes, and a network configuration that matches the environment. 

Blue Coat recommends that you review this section for a high-level overview of the Blue 
Coat ADN implementation. 

This section contains discussions on: 

□ "ADN Components" , below. 

□ "Choosing the Right Deployment" on page 16. 

□ "About ADN Compression" on page 19. 

□ "ADN Security" on page 19. 

ADN Components 

The components of the Blue Coat ADN implementation are: 

□ ADN manager and backup ADN manager to provide routing information and control 
access to the ADN network. 

□ ADN nodes in both branch offices and data centers that can be authenticated (identity 
verified) and authorized (permitted to join the network). 

□ (Optional) Am SG Client manager if you have mobile users or users in small branch 
offices, where it might not be cost-justifiable to deploy an acceleration gateway. 

ADN Manager and Backup Manager 

The ADN manager keeps track of and advertises the routes of the appliances it knows 
about. The ADN manager must be one of the peers in the ADN optimization network. 



Note: Peer refers to any ADN system, manager refers to the ADN system that 

broadcasts route information to all ADN peers and controls peer access to the ADN 
network, and node refers to all non-manager ADN peers. ADN managers can also act 
as nodes on the network. 



A backup ADN manager (optional, but recommended) can also be configured. The ADN 
managers and the registered nodes periodically send keep-alive messages to each other. If 
a node detects the primary ADN manager is not responding, the node automatically fails 
over to the back-up ADN manager. The node repeatedly attempts to restore its connection 
with the primary manager. After the primary ADN manager is responding to the node 
again, the active routing connection of this node switches back to the primary manager. 

If the ADN manager detects a node is not responding, the ADN manager removes the 
node from the database and notifies all other nodes in the network to do the same. 

If both the ADN manager and the backup ADN manager are unavailable, no further 
routing advertisements are broadcast. In this case, routes already known by the peers 
continue to be remembered and used. 
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You also can use the ADN manager and backup manager to authorize which peers are 
allowed to advertise or retrieve route information to and from the ADN manager, and 
whether plain connection requests to the ADN manager are accepted. 

Connections to the ADN manager and backup manager are made at startup and kept 
open as long as ADN is enabled. These connections are referred to as routing connections, 
and are used to advertise configured server subnets and to receive routing table updates 
from the ADN manager. 



Note: Even if you use a transparent tunnel deployment where ADN nodes do not 

require routing information, you must configure each ADN node and register it with 
the ADN manager. If you secure the network (highly recommended), the ADN 
manager is used to authorize ADN peers before they join the network. 



Whenever the ADN manager receives a new advertisement from a node that is joining the 
network, a route update is sent to all the appliances in the ADN optimization network 
that have already established a routing connection; in addition, the current routing table is 
updated. The ADN manager and backup manager can each listen on two ports: one 
accepting the default plain (unsecured) routing connection requests and another 
accepting secure routing connection requests. The plain listener can be shut down if 
routing connections from all ADN nodes are secured. 

To configure the ADN manager and backup ADN manager, see Section B: "Basic ADN 
Setup" on page 21. 

ADN Nodes 

An ADN node is any SG appliance that is configured for ADN optimization and sends 
routing information to the ADN manager and backup ADN manager. A node excludes 
those appliances that are acting as ADN managers and backup ADN managers, although 
the manager and backup manager can also participate as nodes in the network. 

SG Client Manager 

The SG Client typically connects to an SG appliance typically located in a data center. That 
SG appliance provides the SG Client software to users, and maintains the software and the 
client configuration on all clients in the ADN network. Only one SG Client Manager can 
be used in the ADN network. 

For information on using the SG Client and SG Manager, see Chapter 12: "Configuring 
and Using the SG Client” on page 139. 

Choosing the Right Deployment 

You must decide if the network should use explicit tunnel connections, transparent 
connections, or a combination of both. Note that ADN peers always intercept incoming 
transparent connections if ADN is enabled. 

□ Transparent: The branch SG appliance connects to the original server destination 
address and port. If an upstream proxy is capable of transparent tunneling, the 
downstream proxy transfers data over the ADN tunnel. The destination port is 
preserved and is not affected by security being enabled. Skip to "Transparent 
Connections" for more information. 
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□ Explicit: The branch SG appliance connection is established to the ADN peer 
discovered from the routing lookup table. The connection is established to the tunnel 
listening port by default or, if you are preserving the destination port, to the port 
number the application specifies. Skip to "Explicit Connections" on page 18 for more 
information. 

□ Combination: In some circumstances, some ADN nodes can connect transparently, 
while other nodes require explicit routing. Skip to "Combination of Transparent/ 
Explicit Connections" on page 18. 

Transparent Connections 

Transparent connections are used when the network is required to see the original 
destination IP addresses and ports. This requires that each node be configured as an ADN 
node and deployed in in-line mode or virtual in-line mode. 



Note: Beyond setting up an ADN node in an in-line network and configuring the 

ADN node to point to the ADN manager and backup manager, no additional effort is 
required for transparent connections. If you use explicit connections, those 
connections must be explicitly configured. 



Transparent connections take advantage of ADN tunnels that maintain layer-4 
information from the original application connections. Layer-4 information provides an 
administrator more granular control of the ADN network and allows the enforcement of 
network policy. 

In a transparent connection deployment, connections are not established to a particular 
peer in the ADN, as they are in an explicit deployment. An ADN node can establish 
connections to its peers automatically in the absence of any ADN routing information. 

The reject-inbound per interface setting is honored for transparent tunnel interception, 
while the allow-intercept setting is ignored for transparent tunnel interception. 

Internet-bound traffic is automatically accelerated in a transparent deployment if a 
transparent ADN peer is installed at the internet access point and Internet traffic is routed 
correctly. 

Transparent Deployment Load Balancing Scenarios 

In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each node in the ADN cluster. 

If you are using a transparent deployment, you have two options for load balancing. 

□ A dedicated SG appliance as a load balancer; that system makes the decision about 
which node receives which traffic. 

□ A WCCP router or other external load balancer, where the individual nodes in the 
ADN cluster make the informed load balancing decision. 
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Explicit Connections 

Explicit connections are used when maximum network control and granularity is needed. 

Blue Coat supports two explicit connections deployments: explicit or explicit but 
preserving the destination port. In the latter case, the destination port used is the original 
destination port from the client's request, such as port 80 for HTTP. The destination port is 
not affected by the connection setting. 

In both explicit deployments, the server subnets that are fronted by each peer must be 
explicitly configured; the server subnets are then advertised to each ADN node. 

To accelerate Internet traffic in an explicit ADN network, set up a specific ADN peer as the 
Internet gateway. Typically, the Internet gateway is an ADN peer close to the enterprise's 
Internet access point. 



Note: If multiple Internet gateways are available, each peer has its own preferred 

Internet gateway to route all Internet subnets. 



When an ADN peer is configured as an Internet gateway, all other ADN peers forward the 
Internet traffic to this peer. The following logic is used by an ADN peer to determine if the 
connection is destined to the Internet: 

□ If the destination address matches an advertised subnet from any of the ADN peers, 
the connection is forwarded to that peer over the ADN tunnel. 

□ If the destination address matches one of the exempted subnets, the connection is not 
forwarded over the ADN tunnel. 

□ If the destination address does not match an advertised subnet or an exempted 
subnet, the connection is forwarded to an ADN peer that is designated as an Internet 
gateway. 

Explicit Deployment Load Balancing Scenarios 

If you use explicit network connections, you have two options when configuring load 
balancing: 

□ A server subnet, where the branch SG appliance makes the decision about the node 
receiving specific traffic for a destination subnet. This is the easiest and more 
preferred method. For more information, see"Using a Server Subnet" on page 29. 

□ An external load balancer, where that system makes the informed decision about 
which node in the ADN cluster receives specific traffic. For more information, see 
"Using an External Load Balancer" on page 29. 

Combination of Transparent/Explicit Connections 

In some circumstances, it necessary to use explicit connections in addition to the much 
easier and preferred transparent connection deployment. A transparent network that can 
advertise explicit routing connections is supported. This configuration is useful: 

□ When a small branch office is using the SG Client, which allows SGOS functionality 
when a SG appliance is not on site. 

□ If some nodes are not in an in-line configuration or are incapable of initiating 
transparent connections. 
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By default, if an ADN node is advertising routes, explicit connections are made. If no 
explicit routes are found and there is an upstream proxy in the path capable of transparent 
tunneling, the connection is intercepted. This preference is configurable. 

Choosing Which Traffic to Optimize 

When you configure proxy services to manage TCP traffic through the ADN network, you 
can set various attributes that can optimize the traffic for the network. A specific attribute, 
use ADN, allows you to disable ADN for a given service. 

For information on using proxy services, including the services available, refer to Volume 
2: Proxies and Proxy Services. 

About ADN Compression 

ADN compression enables organizations to fully extract every performance benefit 
available when sending data through an ADN tunnel between SG appliances. ADN 
tunnels require that SG appliances on opposite sides of the WAN be members of the same 
ADN network and that the upstream SG appliance either be advertising routes to servers 
to be accessed by appliances on the opposite side of the WAN or be deployed inline so 
that transparent ADN tunnels can be used. 

Traffic accelerated between clients and servers is automatically compressed before being 
sent through the ADN tunnel, decreasing bandwidth usage and optimizing response 
time. ADN compression is often used in conjunction with byte caching and object caching 
to achieve optimum results. In the case of byte caching and compression, byte caching is 
first applied to the data and then the resulting data is compressed. Both features are 
enabled by default to optimize ADN directed traffic. ADN compression for any arbitrary 
protocol can also be configured on the SG appliance using policy; it can also be controlled 
separately for both inbound and outbound traffic on the WAN. 

For more information on byte caching, see Section G: "Manually Re-Sizing a Byte-Cache 
Dictionary" on page 45. 

ADN Security 

ADN networks can and should be secured. You can limit access by: 

□ Authenticating and authorizing the ADN nodes that are allowed on the network and 
prevent unauthorized nodes from participating. 

□ Securing ADN connections. 

Authenticating and Authorizing ADN Nodes 

By default, authentication and authorization are disabled. 

ADN Node Authentication 

Secure ADN requires an appliance certificate for each ADN peer, including the ADN 
manager and backup manager for identification. You can provide your own device 
appliance certificates or obtain Blue Coat-issued appliance certificates from the Blue Coat 
CA server. For the most secure environment. Blue Coat-issued appliance certificates are 
recommended. 

To enable secure ADN, you must enable the appliance authentication profile for the ADN 
network to use before configuring any other security parameters. 
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In secure ADN mode, full mutual authentication can be supported between the ADN 
manager and the ADN nodes and among ADN communicating peers. If authorization is 
enabled on the ADN manager, the peer proxy is authorized through an approval 
mechanism by the ADN manager before joining the network. For more information on 
managing appliance certificates, see Chapter 6: "Authenticating an SG Appliance". 

ADN Node Authorization 

Authorization occurs when the ADN manager gives approval for the device to join the 
network. 

If the profile, authentication, and authorization are configured on each peer, and the 
Pending Peers option is enabled on both the ADN manager and the backup ADN manager 
(if one is configured), the following behavior takes place automatically: 

□ When an ADN node comes up, it contacts the ADN manager for routing information. 

□ The ADN manager extracts the device ID from the connecting ADN node's appliance 
certificate and looks for the device ID in its approved list of ADN nodes. 

• If the device is on the approved list, a request-approved response is sent, 
followed by the route information, and the node joins the network. 

• If the device is not on the approved list, the ADN manager adds the connecting 
node's device ID to a pending-peers list and sends a request-pending response. 
After the peer is moved to the Approved list by the administrator, a request- 
approved response is sent, followed by the route information, and the node joins 
the network. 

• If the Pending Peers option is not enabled and a peer is not on the approved list, 
the ADN manager sends a request-denied response and closes the connection. 
The connecting node closes the connection and updates its connection status. 

• If a peer is deleted from the approved list, the ADN manager broadcasts a 
REJECT-PEER to all nodes to delete this node and terminate any existing ADN 
connections to it. No new connections are routed through the deleted ADN node. 

For information on configuring authentication and authorization on each ADN node, see 
"Configuring ADN Security Settings" on page 32. 

Securing ADN Connections 

By default, ADN routing and tunnel connection requests are unauthenticated and all 
ADN protocol messaging and compressed application data are transferred in plaintext. 
For maximum security, you can configure the ADN network to secure ADN routing and 
tunnel connections using standard SSL protocol, which provides authentication, message 
privacy, and message authenticity security services, regardless of the application traffic 
that is being accelerated or tunneled. 

In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode 
to listen for routing and tunnel requests. 

When secure ADN is enabled, any existing plain outbound connections are dynamically 
secured by activating SSL according to the secure-outbound setting. 

For information on optimizing and securing ADN tunnels, see Section D: "Securing the 
ADN Network" on page 32 and Section F: "Advanced Tunnel Optimization" on page 42. 
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Section B: Basic ADN Setup 

Basic ADN setup includes: 

□ Configuring each node in an in-line deployment; if you are configuring an explicit 
deployment, you do not need to configure the network in an in-line deployment. 

□ Plugging each node in. 

□ Enabling the ADN manager and backup manager on each node, starting with the 
ADN manager and backup manager themselves. 

If you are using a transparent connection deployment without load balancing, ADN 
configuration is complete at this point. 

If you are using an explicit connection deployment, a transparent connection deployment 
with load balancing, or if you are securing the ADN network (highly recommended), after 
finishing this section you must continue with: 

□ "Explicit Load Balancing" on page 28, for explicit deployment. 

□ "Transparent Load Balancing" on page 24, for transparent deployment. 

□ Section D: "Securing the ADN Network" on page 32. 

Defining the ADN Manager 

When an SG appliance connects to the primary ADN manager, subnet information is sent 
to the manager, including: 

□ Peer ID: The serial number of the device. This is a globally unique identifier for the 
peer SG appliance that is used as a key to select the dictionary of tokens to use. 

□ Data IP Address and Port: The destination IP address and port number that a branch 
proxy should use when establishing an explicit (non preserve-dest-port) tunnel 
connection. 

□ Server Subnet Advertisements: The list of server subnets the SG appliance contains 
are sent to the ADN manager. 

The first step in configuring an ADN network is to define the primary ADN manager. 
Blue Coat also recommends deploying a backup ADN manager to prevent loss of routing 
information should the primary ADN manager become unavailable for any reason. The 
ADN manager and backup ADN manager must be configured on each peer that is joining 
the ADN network. 

To enable ADN optimization and define the primary/backup ADN managers: 



Note: Fill in all fields on this pane before clicking Apply. 



1. Select Configuration > ADN > General. 
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General Device Security | Connection Security 


2 “=* 


0 Enable Application Delivery Network 




- Primary ADN Manager 


3 


" c> ® Self O IP Address: 




Status: ADN connect successful 




- Backup ADN Manager 


4 


Self O IP Address: 




Status: Not configured 




r Manager Ports 


5 


^ Plain Manager Port: 3034 




Secure Manager Port: 3036 


a 




Reconnect to Managers Refresh Status 



2. Select Enable Application Delivery Network. 

3. Primary ADN Manager: Enter the IP address of the primary ADN manager. This can be 
the SG appliance itself or any peer on the ADN optimization network. 

4. Backup ADN Manager (Optional but highly recommended): Enter the IP address of the 
backup ADN manager or select the Self radio button if this SG appliance is the backup 
manager. 

5. Manager Ports: The ports are set to 3034 (for plain routing connections) and port 3036 
(for secure routing connections). 

6. Click Reconnect to Managers to connect to the ADN manager and backup ADN 
manager, if one is configured. 



Note: You cannot select this option until you select the primary ADN manager and 

apply the changes. The ADN manager does not exist until the changes are applied. 



7. Click Apply to commit the changes to the SG appliance. 
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Section C: Transparent and Explicit Connection Deployments 

If you are configuring a transparent connection deployment without load balancing, 
remember that ADN peers always intercept incoming transparent connections if ADN is 
enabled. No special configuration is required after basic ADN configuration is completed 
unless you use transparent connection load balancing or if you need to configure a 
combined (explicit and transparent) connection network. 

The basic steps for configuring a combined transparent / explicit deployment or a pure 
explicit deployment are: 

□ Connect the nodes in in-line mode or virtual in-line mode only for those nodes that 
are using transparent connections. 

□ (Optional) Secure the ADN network: 

• Configure the ADN nodes for ADN authentication and authorization for 
maximum security (see "Configuring ADN Security Settings" on page 32). The 
settings on each system should be identical. 

• Configure secure tunnels (see Section F: "Advanced Tunnel Optimization" on 
page 42). 

□ (Optional) Configure the load balancing parameters for each node to be used in load 
balancing (see "Explicit Load Balancing" on page 28 or "Transparent Load Balancing" 
on page 24). 

To configure transparent connections, including transparent connection load balancing, 
continue with the next section. 

To configure explicit connections, including explicit connection load balancing, see 
"Configuring an Explicit Deployment" on page 26. 

To configure a combined connection deployment, skip to "Configuring a Combined 
(Transparent and Explicit) Deployment" on page 31. 

Configuring a Transparent Deployment 

After you have completed basic ADN configuration, transparent connections are made 
automatically. No further configuration is required, unless you need to configure 
transparent load balancing. 



Transparent Deployment Notes 

□ The first proxy in the chain that supports transparent tunnels and is on the same ADN 
network intercepts ADN transparent tunnel connections. 

□ In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each node in the ADN cluster. 

□ Transparent load balancing relies on connection forwarding clusters for proper 
operation. All nodes in an ADN load balancing group must be part of the same 
connection forwarding cluster. 

□ If connection forwarding is not set up correctly, load balancing will fail. For 
information on connection forwarding, see Chapter 4: "TCP Connection Forwarding" 
on page 59. 
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Transparent Load Balancing 

In transparent load balancing, routes are not advertised, and configuration of load 
balancing must be done on each node in the ADN cluster. 

If you are using a transparent deployment, you have two options for load balancing. 

□ A dedicated SG appliance as a load balancer; that system makes the informed 
decision about which node receives which traffic. 

□ A WCCP router or other external load balancer, where the individual nodes in the 
ADN cluster make the informed load balancing decision. 

Using the Blue Coat Appliance as a Load Balancer 

When a Blue Coat appliance is used as the external load balancer, it makes the decisions 
about which traffic is directed to which node. 




Red Arrows = Data Packets/Connections ADN Cluster 

Group 1 



Blue Coat SG Appliance is 
Decision Maker 

To configure transparent load balancing with a dedicated Blue Coat appliance as the 
decision maker: 

□ Deploy the load-balancing SG appliance in-line so that it can transparently intercept 
all traffic. 

□ Enable load balancing on all nodes by going to Configuration > ADN > Tunneling > Load 
Balancing, and selecting the Enable Load Balancing checkbox. 



24 



Chapter 2: Configuring an Application Delivery Network 



Section C: Transparent and Explicit Connection Deployments 



□ (Optional) Configure each box in the cluster with the same load-balancing group 
name. 

□ On the Blue Coat appliance that's acting as the dedicated load balancer, select Act as 

load balancer only through the Configuration > ADN >Tunneling > Load Balancing tab. 

□ Put all ADN nodes into a connection forwarding cluster. For more information, see 
Chapter 4: "TCP Connection Forwarding" on page 59. 



Note: No special configuration is required for client IP spoofing beyond standard 

configuration, which is to enable reflect-client-ip on the branch SG appliance and to 
set the concentrator SG appliance to allow client-ip spoofing under ADN tunneling. 



Using a WCCP Router or L4 Switch as a Load Balancer 

Using a WCCP router or L4 switch as a transparent load balancer is similar to using an SG 
appliance as a transparent load balancer, except that WCCP router or L4 switch must be 
configured on each system in the cluster. In this scenario, the router or switch cannot 
guarantee ADN peer affinity because the router cannot use the peer ID as input for its 
hash. Because of this, the ADN nodes make the actual informed routing decisions. 



Branch SG Appliance 




WCCP Router 
Group WCCP 1 



Origin Content Server 



ADN Manager 



Legend: 

Black Arrows = ADN Manager Connections 
Red Arrows = Data Packets/Connections 



ADN Cluster 
Group WCCP 1 



Each Node is Decision Maker 



To configure transparent load balancing with the nodes in the ADN cluster as the decision 
makers: 
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□ Enable load balancing on all nodes by going to Configuration > ADN > Tunneling > Load 
Balancing, and selecting the Enable Load Balancing checkbox. 

□ (Optional) Set the same group name on all of the nodes in the cluster. 

□ Put all ADN nodes into a forwarding connection cluster. For more information, see 
Chapter 4: "TCP Connection Forwarding" on page 59. 

□ Configure WCCP settings on all nodes. For more information, see Chapter 17: 

"WCCP Settings" on page 239. 

□ Configure WCCP router settings. Review the vendor's documentation for 
information. 



Note: Note: If client IP spoofing is desired, you must configure WCCP so that both 

traffic from the Branch Appliance to the Origin Content Server and traffic from the 
Origin Content Server to the Branch Appliance is redirected through WCCP. This 
requires configuring WCCP on multiple interfaces on your router, or configuring "in/ 
out" rules. If specific ports are desired (rather than all ports), you must configure both 
source-port and destination-port rules in two different service groups. 



Configuring an Explicit Deployment 

Complete the following steps to configure an explicit deployment: 

□ Configure server subnets on each peer and enable an Internet gateway (see 
"Managing Server Subnets and Enabling an Internet Gateway" ). 

□ (Optional) Preserve the destination port (see "Preserving the Destination Port" on 
page 28). 

□ Configure explicit load balancing (see "Explicit Load Balancing" on page 28) 

Managing Server Subnets and Enabling an Internet Gateway 

The server subnets you create here are advertised by this peer upon joining the explicit 
ADN network. You can also enable the peer as an Internet gateway. In addition, subnets 
not intended to go over ADN tunnels or to be routed to Internet gateways can be 
configured as exempt subnets. 



Note: You can also configure the exempt subnet capability through policy that 

allows you to disable ADN tunnel for specific connections. For more information, 
refer to Volume 10: Content Policy Language Guide. 



To create server subnets for this peer: 

1. Select Configuration > ADN > Routing > Server Subnets. 
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2 . 

3. 



Added 

Server 

Subnet 



Server Subnets 



Server Subnets 



Server 5ubnets 



Internet Gateway 




3 



2 Add J ( Remove ] ( Clear All 



Click Add. 



In the Add IP/Subnet dialog, enter the following information and click OK when you 
are done: 



• IP / Subnet Prefix field: Enter either an IP address or an IP address and subnet in 
Classless Inter-Domain Routing (CIDR) notation (for example, 192 . 168 . 0 . 1 / 16 ). 

• Subnet Mask field: Use this field if you entered only an IP address in the preceding 
field (in other words, if you used CIDR notation in the preceding field, you do not 
need to enter a value in this field). 

• To remove excluded subnets, click the subnets to remove and click Remove. You 
must confirm the action. 

• To clear all excluded subnets, requiring traffic from all IP addresses and subnets 
to be tunneled, click Clear all. You must confirm the action. 

4. (Optional) Repeat for additional routes. 



5. Click Apply to commit the changes to the SG appliance. 



To enable this peer as an Internet gateway: 

1. Select Configuration > ADN > Routing > Internet Gateway. 
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Server Subnets Internet Gateway Advanced 

[^1 Enable this ProxySG as an Internet Gateway for all subnets except the folletoin§r 2 

Exempt Subnets 

10 . 0 . 0 . 0/8 

172.16.0.0/12 
|l92.168. 0.0/16 



10.9.59.0/24 




2. Select the Enable this SG as an Internet Gateway for all subnets except the following 

checkbox. 

3. Click Add. 

4. Add the IP/Subnet that must not be routed to Internet gateway(s); click OK. 

5. (Optional) Repeat for additional subnets. 

6. Click Apply to commit the changes to the SG appliance. 

Preserving the Destination Port 

Complete the following procedure. 

To preserve the destination port: 

1. Select Configuration > ADN > Tunneling > Connection. 



Connection | Network | Load Balancing | Proxy Processing 

- Inbound 

Plain Tunnel Port: [3035 

Secure Tunnel Port: I 3037 



r Outbound 

| | Connect using ADN transparent tunneling when possible 

[^1 When a route is available, preserve the destination TCP port number when connecting to the ADN peer 

2. Select the checkbox for When a route is available, preserve the destination TCP port 
number when connecting to the ADN peer. 

Explicit Load Balancing 

Of the two explicit load balancing types, server subnet or external load balancer, the 
server subnet is the preferred and easiest to use. While the server subnets must be 
configured, no additional load balancing settings must be made, and the ADN nodes 
explicitly advertise their own IP addresses. 
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Using a Server Subnet 

If you use an explicit deployment, or if you just want to load balance traffic destined to a 
specific subnet, configure the subnet as a server subnet on each ADN node within that 
group. 

To forward the connection destined to the load balanced subnet, each ADN node selects 
the preferred node from the list of all peers fronting that subnet. This is done by ranking 
the list of all nodes fronting a given subnet from highest to lowest. The node with the 
highest rank is chosen to route the client traffic for that subnet. 




Branch SG Appliance is 
Decision Maker 



Using an External Load Balancer 

If you use explicit deployments, you can rely upon an external load-balancer fronting a 
group of ADN nodes. The load balancer is configured to distribute the load among the 
nodes that it fronts using client/ IP address affinity. 

The external load balancer provides more control than the server subnet, but it requires 
more configuration. For example, you must create an external VIP address on the 

Configuration > ADN > Tunneling > Load Balancing tab on each system in the ADN cluster; 
the VIP address is explicitly advertised by the ADN manager. 

Both server subnet and external load balancer use a cluster of ADN nodes for load 
balancing. The cluster is formed by ADN nodes that are configured to the same ADN 
manager and are advertising the same server subnets. 
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Red Arrows = Data Packets/Connections ADN Cluster 



External Load Balancer 
is Decision Maker 

Whether you are using server subnets or an external load balancer, you must configure 
server subnets. If you are using an external load balancer, you must also configure the 
external load balancer with a VIP address and put the address in the Load Balancing tab. 
Continue with the next procedures to configure explicit load balancing. 

Explicit Load Balancing Procedures 

If you want to use either the server subnet load balancing deployment or the external load 
balancing deployment, you must configure server subnets. If you are using the external 
load balancing deployment, you must also configure the external load balancer with a VIP 
address. 

To configure server subnets: 

1. Go to Select Configuration > ADN > Routing. 

2. Click Add. 

3. Add the IP/Subnet route to be advertised by the ADN manager; click OK. 

4. (Optional) Repeat for additional routes. 

For detailed information about configuring server subnets, see "Managing Server Subnets 
and Enabling an Internet Gateway" on page 26. 
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To configure VIP addresses: 

1. Select Configuration > ADN > Tunneling > Load Balancing. 

2. Enter the VIP address of the external load balancer. 



Note: The VIP address is added from the Load Balancing tab of the App Delivery 

Network menu, not the Advanced tab of the Network menu. 



3. Click Apply to commit the changes to the SG appliance. 

The address must be entered on each ADN node in the cluster. 

Configuring a Combined (Transparent and Explicit) Deployment 

If you set up a transparent ADN network with no explicit connections, no additional 
configuration is required for transparent tunnel connections to work unless you want to 
configure load balancing. To configure transparent load balancing, skip to "Setting Device 
Security" on page 32. 

If you set up a combined ADN network with both explicit and transparent connections, 
you must: 

□ Configure the explicit routes you need (see "Managing Server Subnets and Enabling 
an Internet Gateway" on page 26). 

□ Configure the routing preference for each ADN node to tell ADN peers to prefer 
transparent connections (see "To configure the routing preference:" ). The default is to 
always use advertised, explicit, routes. 

□ Set the manager listening mode to Plain read-only mode if SG Clients are in the 
network (see "To configure ADN manager and tunnel listening mode and ports:" on 
page 35. 

□ Configure transparent or explicit load balancing, if necessary. For more information, 
see "Transparent Load Balancing" on page 24 or "Explicit Load Balancing" on page 
28. 

To configure the routing preference: 

1. Select Configuration > ADN > Routing > Advanced. 



Server Subnets | Internet Gateway Advanced 

r Routing Preference 

® Tell ADN peers to always use advertised routes 
® Tell ADN peers to prefer transparent connections over advertised routes 

2. Select the Tell ADN peers to prefer transparent connections over advertised routes radio 
button. 
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Section D: Securing the ADN Network 

Depending on your environment, you might need to secure your ADN network to 

provide the following services: 

□ Host validation: Securing the ADN network allows you to be sure that the ADN peers 
are talking to the right devices and that the peer is authorized to join the ADN 
network. 

□ Privacy: Privacy can be an issue, especially for tunnels that carry application data. 
You can configure the ADN network to secure ADN routing and tunnel connections 
using standard SSL protocol. SSL tunnels provide authentication, message privacy, 
and message authenticity security services, regardless of the application traffic that is 
being accelerated or tunneled. 

□ Message authenticity: Ensure that messages sent over ADN connections are not 
altered. Messages include the route information sent over the routing connections and 
compressed application data sent over the tunnel connections. 

Secure ADN implementation includes: 

□ Device authentication, managed through the device authentication profile. 

□ Securing the device, including device authentication profile selection and device ID- 
based peer authorization. 

□ Securing the connections, both inbound and outbound connection security control. 

□ Configuring the SSL proxy. 



Note: If you only want secure routing connections to the ADN manager, an SSL 

license is not required. Secure tunnel connections for applications such as CIFS, 
MAPI, TCP Tunnel, HTTP, or HTTPS/SSL, are dependent upon an SSL license. 



Configuring ADN Security Settings 

For information on setting device security, continue with the next section. For information 
on setting connection security, continue with "Securing Connections" on page 34. 

Setting Device Security 

For maximum security, configure the ADN network for both device authentication and 
device authorization. Device authentication must be configured first. 



Note: If the device being configured for authentication has Internet access, 

acquisition of the SG appliance certificate is automatic. If you use your own appliance 
certificates and profile, or if the affected device does not have Internet access, manual 
device authentication is required. 



For information on configuring device authentication, see Chapter 6: "Authenticating an 
SG Appliance” on page 87. 
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After the device authentication has been set up, point the ADN manager and ADN 
backup manager to the profile that is being used for authentication. Then enable 
authorization for maximum security. 



Note: You cannot enable device authorization before configuring the ADN manager 

and backup ADN manager. You can, however, configure the ADN manager and 
backup ADN manager and then, without pressing Apply, enable device authorization. 
Then press Apply to save both tabs. 



To set device security: 

1. Select Configuration > ADN > General > Device Security. 



2 . 



General 



Device Security 



Connection Security 



2a_ 

2b- 

2c- 

2c 



Device Authentication Profile: bluecoat-appliance-certificate v 

Extracted Device ID: 4605060001 

Authorization 



p| Validate ADN Peer Device IDs 
Primary Manager Device ID: self 
Backup Manager Device ID: 



Retrieve Manager IDs 



Retrieved Manager IDs 



Primary Manager Device ID: self 
Backup Manager Device ID: 2505060056 



Accept 



Reject | 



Configure the Device Security settings: 

a. Device Authentication Profile: From the drop-down list, select the profile that 
you previously associated with the device authentication keyring. Note that 
only devices using the same profile are authenticated. 

b. Extracted Device ID: The device ID that was extracted based on the selected 
profile is automatically displayed. 



Note: The device ID is only used for security. The peer ID is the serial number. 



c. To enable authorization, select the Validate ADN Peer Device IDs checkbox. 

• If the primary or backup ADN manager is Self, the device ID is automatically 
displayed. 

• If the primary or backup ADN manager is a different system, click the 
Retrieve Manager IDs button to see the device ID. Click Accept to add the 
Manager device ID to the Authorization field. 



Note: Authorization of devices is not complete until the devices have been 

approved to be part of the network. For more information on approving devices, see 
"ADN Node Authorization" on page 20. 
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3. Click Apply to commit the changes to the SG appliance. 

Securing Connections 

Use the Connection Security tab to set: 

□ Manager and Tunnel Listening Mode. 

□ Secure Outbound Connections. 

Listening Mode Options 

In secure ADN mode, you can specify that the ADN manager and tunnel use secure mode 
to listen for routing and tunnel requests. By default, ADN routing and tunnel connection 
requests are unauthenticated and all ADN protocol messaging and compressed 
application data are transferred in plain text. 

You must enable the device authentication profile before setting any other security 
parameters. 

After the profile is configured, the following security modes are automatically set: 

□ Secure-outbound: (Secure Proxies) Both outbound routing and secure proxy 
connections are secured. You can also select the radio button to: 

• Not secure ADN connections. 

• Secure only ADN routing connections. 

• Secure all ADN and routing connections. 



Note: The secure-outbound feature is dependent upon an SSL license. 



□ Manager-1 istening-mode: (Both) Listen for requests on two ports: plain and secure. If 
your deployment requires a different ADN manager listening mode, you must 
explicitly configure it. Other options available are: 

• Secure Only. 

• Plain Only. 

• Plain Read-Only. This mode is recommended if your network uses SG clients. 

□ Tunnel-listening-mode: (Both) Listen for requests on two ports: plain and secure. Other 
options are: 

• Secure Only (Note that tunnel listening mode cannot be set to secure-only if SG 
Clients exist on the ADN network). 

• Plain Only. 

Secure Outbound Connections 

When secure ADN is enabled, any existing plain outbound connections are dynamically 
secured by activating SSL according to the secure-outbound setting. Determine which 
outbound ADN connections are secured by changing the secure-outbound parameter. If 
you select: 

□ None: Neither routing nor tunnel connections are secured. Secure proxy connections 
bypass ADN connections and go directly to the origin content sever. 
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□ Routing-only: Only routing connections are secured. Secure proxy connections bypass 
ADN connections and go directly to the origin content sever. 

□ Secure Proxies: Routing connections and secure proxy connections are secured. 

□ ALL: All outbound connections are secured. 



Note: Securing all outbound ADN connections should be done only if the platform 

has sufficient capacity to handle the extra overhead. 



The table below describes secure outbound behavior with various applications. 



Table 2-1 . Secure Outbound Behavior 



Secure-Outbound 

Setting 


Routing 

Connections 


Application Connections 


CIFS 


SSL Proxy 
Intercept Mode 


SSL Proxy 
Tunnel Mode 


None 


Plain Text 


Plain Text 


Bypass ADN 


Bypass ADN 


Routing-only 


Encrypted 


Plain Text 


Bypass ADN 


Bypass ADN 


Secure Proxies 


Encrypted 


Plain Text 


Encrypted 


Encrypted by application 


All 


Encrypted 


Encrypted 


Encrypted 


Encrypted by application 



To configure ADN manager and tunnel listening mode and ports: 
1. Select Configuration > ADN > General > Connection Security. 



General Device Security Connection Security 

- Manager Listening Mode 

O Secure Only O p l ain Read-Only ® Plain Only Q Both 

- Tunneling Listening Mode 

O Secure Only ® Plain Only O Both 

- Secure-Outbound Mode 

® Do not secure ADN connections 
O Secure only ADN routing connections 

O Secure ADN routing connections and tunnel connections made by secure proxies 
0 Secure all ADN routing and tunnel connections 

2. To configure manager listening mode and ports: 

• To change the manager listening mode, go to Configuration > ADN > General > 
Connection Security. The default is Plain-only before the device authentication 
profile is selected. After the device authentication profile is selected, the manager 
listening mode switches to Both by default. 

• To change the manager listening ports, go to Configuration > ADN > General > 
General. The default is plain port 3034 and secure port 3036. 
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3. To configure tunnel listening mode and ports: 

• To change the tunnel listening mode, go to Configuration > ADN > General > 
Connection Security. The default is Plain-only before the device authentication 
profile is selected. After the device authentication profile is selected, the manager 
listening mode switches to Both by default. 

• To change tunnel listening ports, go to Configuration > ADN > Tunneling > 
Connection. The default is plain port 3035 and secure port 3037. 

The tunnel listening port is used only if there are explicit tunnel connections to 
this ADN node using the non-preserve-dest-port mode. 

4. Click Apply to commit the changes to the SG appliance. 

Authorizing Devices to Join the Network 

After a node is configured for authentication (device security) and peer validation is 
enabled on the ADN manager, the node must be accepted by the ADN manager and the 
backup ADN manager, if configured, before the device is allowed to join the network 
(authorization) . 

□ When an ADN node comes up, it contacts the ADN manager for routing information. 

□ If secure-outbound is None on the ADN node and the ADN manager's listening mode 
is not secure-only, the ADN node connects to the plain manager listening port and 
immediately joins the ADN network. 

□ If the ADN node connects to the secure manager listening port, the ADN manager 
extracts the device ID from connecting ADN node's appliance certificate and looks for 
the device ID in its approved list of ADN nodes. 

• If the device is on the approved list, a request-approved response is sent, 
followed by the route information, and the node joins the network. 

• If the device is not on the approved list, the ADN manager adds the connecting 
node's device ID to the pending-peers list and sends a request-pending 
response. After the peer is moved to the Approved list by the administrator, a 
request-approved response is sent, followed by the route information, and the 
node joins the network. 

• If the Pending Peers option is not enabled and a peer is not on the approved list, 
the ADN manager sends a request-denied response and closes the connection. 
The connecting node closes the connection and updates its connection status. 

• If a peer is deleted from the approved list, the ADN manager broadcasts a 
REJECT- PEER to all nodes to delete this node and terminate any existing ADN 
connections to it. No new connections are routed through the deleted ADN node. 
To have the denied peer rejoin the ADN network, go to ADN > Config > General > 
Reconnect to Managers. 

To approve a device to join the network: 



Note: Device security must be enabled on all ADN peers you want to join the 

network before you complete this procedure on the ADN manager and backup ADN 
manager. For more information, see "Setting Device Security" on page 32. 
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1. Go to Configuration > ADN > Manager > Approved Peers. 

2. To manage peers that you want to be approved to join the network or that have 
previously been approved to join the network: 

• Add peers to the list by selecting Add; a dialog box displays that allows you to 
enter one or a group of peers by listing one to a line. Click OK when through. If 
the device contacts the ADN manager and is on the approved list, a REQUEST- 
APPROVED response is sent, followed by the route information, and the node joins 
the network. 

• Remove peers by highlighting the peer or peers and selecting Remove. If a peer is 
deleted from the approved list, the ADN manager broadcasts a REJECT-PEER to 
all nodes to delete this node and terminate any existing ADN connections to it. 
No new connections are routed through the deleted ADN node. 

3. Click Apply to commit the changes to the SG appliance. 

To manage devices not yet approved to join the network: 

If a peer is configured to contact the ADN manager on startup but has not been added to 

the approved list, the ADN manager adds the peer to the list of pending peers if the Allow 

Pending Peers checkbox is selected. The peer moves from the Pending Peers list to the 

Approved Peers list only through human action. 

1. Go to Configuration > ADN > Manager > Pending Peers. 



Approved Peers Pending Peers 

0 Allow Pending Peers 

Pending Peers 

Device ID Connecting from Action 



Accept ] [ Reject ] ( Leave Pending ) ( Refresh 
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2. Select the Allow Pending Peers checkbox. 

3. To manage pending peers: 

• Highlight a peer and click Accept or Reject; alternatively, you can select or reject 
all peers in the list by clicking Accept All or Reject All. If accepted, the peer moves 
to the Approved list; if not, it is dropped from the Pending Peers list. 

• You can also leave peers in the pending list by not selecting them or selecting 
them and clicking Leave Pending. 

4. Click Apply to commit the changes to the SG appliance. 

Approved/Pending Notes 

□ Approved lists on the primary and backup ADN managers are not automatically kept 
in sync. You must approve peers on both the primary and backup ADN managers. 
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Section E: ADN Network History, Statistics, and Health Metrics 

After ADN optimization has been enabled and is processing, you can review byte caching 
history and various byte caching statistics. 

Reviewing ADN History 

Review the Traffic Mix and Traffic History tabs in Statistics to be sure that ADN is 
working. For more information on Traffic Mix and Traffic History, refer to the statistics 
information in Volume 9: Managing the Blue Coat SG Appliance. 

To review ADN history, select Statistics > ADN History. 




Inbound Compression Gain represents traffic received from another peer. Outbound 
Compression Gain represents the traffic sent to other peers. 

The values include both compression and byte-cache gain. 

Reviewing Byte-Caching Statistics 

To review byte caching statistics, select Statistics > Advanced and select the ADN link from 
the list. 

Per connection real time statistics are provided. Each connection has the following details: 

□ Client IP address /port. 

□ Server IP address/port. 

□ Bytes received from the application: The total bytes received from the client/server/ 
application proxy. 
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□ Bytes sent to the application: The total bytes sent to the client/ server/ application 
proxy. 

□ Bytes received from the peer SG appliance: The bytes received on the ADN tunnel 
connection from the peer at the other end of the WAN link. (This is compressed unless 
byte caching is disabled). 

□ Bytes sent to the peer SG appliance: The bytes sent on the ADN tunnel connection to 
the peer at the other end of the WAN Link. (This is compressed unless byte caching is 
disabled). 

□ Duration: The lifetime of this connection. 

Reviewing ADN Health Metrics 

You can see the state of the ADN network, specifically the ADN node, by checking the 

Statistics > Health > General tab. 

The status can have the values as shown in the following table. The information is meant 

for diagnostic and debugging purposes. 
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Table 2-2. Connectivity to ADN Routing Manager Health Metric 



Status 


Message 


Description 


State 


ADN Health Status 


Connected 


The ADN node is connected to the ADN 
manager, ready to receive any route /peer 
updates. 

If a backup manager exists, this state 
indicates the node is connected to both 
Managers. 


OK 




Functionality 

Disabled 


ADN functionality is not enabled. 


OK 




Not operational 


ADN functionality is not operational yet — 
components are starting up or shutting 
down. 


OK 




Connection 

Approved 


The ADN node has been approved to 
connect to the ADN manager. 


OK 




Connecting 


The ADN node is in process of connecting 
to ADN manager. 


OK 




Partially Connected 


The ADN node is connected to one ADN 
manager but not the other. 


Warning 




Mismatching 
Approval Status 


The ADN node is approved by the current 
active ADN manager but is rejected by the 
backup manager. This warning only exists 
if a backup ADN manager is configured. 


Warning 




Approval Pending 


The ADN node is awaiting a decision from 
the active ADN manager for the node's 
request to join the ADN network. 


Warning 




Disconnected 


The ADN node is not connected to the 
ADN manager and cannot receive route/ 
peer information. 

If a backup manager is configured, this 
state indicates the node is disconnected 
from both manager nodes. 


Critical 




Connection Denied 


The ADN node is rejected by the ADN 
managers in the node's request to join the 
ADN network. 


Critical 


ADN Manager Status 


Not an ADN 
manager 


The ADN node is not an ADN manager. 


OK 




No Approvals 
Pending 


All ADN nodes that are requesting to join 
the network are already on the approved 
list. 


OK 




Approvals Pending 


ADN nodes are requesting to join the 
network. The approvals are made by the 
administrator. 


Warning 
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Section F: Advanced Tunnel Optimization 

Tunnel connections are between the branch and concentrator proxies and are made on 
demand. To reduce connection startup latency, tunnel connections are pooled and reused. 

If a route is present, proxies that support ADN optimization use an ADN tunnel 
connection. Data traveling over the tunnel connection is subject to byte caching, 
compression, and encryption, per the defined policies. 

The tunnel connection occurs independently of the ADN optimization options chosen for 
that connection. These options can be configured for specific services and can also be 
modified in policy. 



Note: Encryption options cannot be set through policy. 



Optimization options include byte caching and gzip compression; byte caching and gzip 
compression can be controlled separately for inbound and outbound traffic on the WAN. 

By default, ADN routing and tunnel connection requests are unauthenticated and all 
ADN protocol messaging and compressed application data are transferred in plaintext. 
For maximum security, you can configure the ADN network to secure ADN routing and 
tunnel connections using standard SSL protocol, which provides authentication, message 
privacy, and message authenticity security services, regardless of the application traffic 
that is being accelerated or tunneled. 

For information on securing the network, see Section D: "Securing the ADN Network" on 
page 32. 



Setting Advanced Tunneling Parameters 

The tunneling parameters you set determine the behavior when you have special 
environmental needs where the default parameters are not adequate. These parameters 
generally do not need to be changed. Parameters that can be changed include: 

□ Connection Settings (see "To configure ADN manager and tunnel listening mode and 
ports:" on page 35). 

□ Network Settings (see "To configure network tunneling settings:" ). 

□ Load Balancing Settings (see "Transparent Load Balancing" on page 24 and "Explicit 
Load Balancing" on page 28). 

□ Proxy Processing Settings (see "To change parameters for proxy processing:" on page 
43). 

To configure network tunneling settings: 

1. Select Configuration > ADN > Tunneling > Network. 
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Connection Network j Load Balancing | Proxy Processing 

- Reflect Client IP 

When an inbound ADN tunnel connection requests Client IP reflection: 

O Reject the request 

0 Allow the request and reflect the client IP 
0 Allow the request but connect using a local IP 



- TCP Settings 

ADN Tunnel TCP Window Size: | 655360 



2. Determine the behavior of the concentrator proxy when a branch proxy requests 
client IP reflection (sending the client's IP address instead of the SG appliance IP 
address to the upstream server). 

This setting is based on whether the concentrator was installed in-line. If the 
concentrator proxy is in-line and can do IP reflection, you can allow client IP address 
reflection requests from clients. If not, set this option to either Reject the Request or 
Allow the request but connect using a local IP to accept the requests but ignore the 
client IP address and use a local IP address. 

3. In the TCP Settings panel, enter the TCP window size to be used on ADN 
optimization tunnel connections. This setting only needs to be changed for high 
bandwidth and high delay environments, such as satellite links. The range is between 
8 KB and 4 MB (8192 to 4194304), depending on your bandwidth and the round-trip 
delay. 



Note: If you know the bandwidth and round trip delay, you can compute the 
value to use as, roughly, 2 * bandwidth * delay. For example, if the bandwidth of 
the link is 8 Mbits/sec and the round-trip delay is 0.75 seconds: 

window =2*8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes 

The setting in this example would be 1500000 bytes. This number goes up as either 
bandwidth or delay increases, and goes down as they decrease. 

You can increase the window size based on this calculation but do not decrease the 
window size if the result is less than 64K. 

The window-size setting is a maximum value; the normal TCP/IP behaviors 
adjust downward as necessary. Setting the window size to a lower value might 
result in an artificially low throughput. 



4. Click Apply to commit the changes to the SG appliance. 

To change parameters for proxy processing: 

1. Select Configuration > ADN > Tunneling > Proxy Processing. 

Connection | Network | Load Balancing Proxy Processing 

r Proxy Processing 

Enable proxy processing for incoming ADN tunnel connections for the following protocol: 

□ http 
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2. (Optional) If the concentrator is required to perform HTTP proxy processing on 

requests arriving over an ADN tunnel, select HTTP. For most deployments, this is not 
needed. All proxy processing always happens at the branch proxy; generally 
speaking, the concentrator proxy just compresses and decompresses bytes and 
forwards them to and from the server. If this setting is enabled, proxy processing 
happens at both the branch and concentrator. 



Note: If you enable this setting, do not duplicate any of the policy that exists at 

the branch, since the branch settings still apply. Depending on the policy 
involved, doing the processing twice can cause problems (such as doing URL 
rewrite multiple times) or it might just be unnecessary, taking up valuable 
resources. 



3. Click Apply to commit the changes to the SG appliance. 
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Section G: Manually Re-Sizing a Byte-Cache Dictionary 

The size of a byte-cache dictionary is dynamically based on the amount of traffic between 
two peers. Generally, the dynamic settings are acceptable; you do not need to change the 
dictionary size. Only if you determine that the algorithm performance does not guarantee 
a sufficient dictionary size for a specific peer should you manually set the dictionary size. 

The byte cache itself, consisting of all data seen on the network, is stored on disk. 
However, byte caching stores index data in RAM. You cannot change the amount of 
memory allocated for a peer, but you can manually set the amount of disk space to be set 
aside. The amount of memory set aside is based on the disk space. 

A table of peer rankings and dictionary sizes is created and maintained by the SG 
appliance. Peers are allocated dictionary space in order starting with the highest ranking 
peer in the table until each peer has been allocated resources, or maximum available 
amount of byte cache memory is reached. 



Note: The rank table can track peers that are using SGOS 5.1.3, but these peers 

cannot dynamically re-size or delete their dictionary. 



After the maximum available resources are reached, any peers that have not been 
allocated a dictionary cannot use byte caching. If those peers have existing dictionaries, 
the tunnels are downgraded to gzip compression only and the existing dictionary is 
deleted. 

A node can re-negotiate a new shared dictionary size with one of its peers, and the 
dictionaries grow or shrink to their new resource levels. The final shared dictionary sizes 
between two peers is the minimum dictionary size that each peer tries to negotiate. To 
guarantee a minimum dictionary size, the value should be set on both peers. (See "To 
manually resize byte cache dictionaries from the Statistics tab:" on page 46.) 

When a peer joins the network, it is added to the peer ranking table. How much dictionary 
space the peer is allocated depends: 

□ If the maximum amount of resources have already been reached, the new peer can do 
gzip compression only. 

□ If the maximum amount of resources have not been reached: 

• If no history exists for this peer, then the peer negotiates a default dictionary size 
based on its maximum memory and maximum disk space. 

• If history does exist for the peer and the peer's rank guarantees the peer a 
dictionary, the peer is allocated a dictionary based on that history. 

The peer ranking table is persistent across system reboots; the dictionaries themselves are 
re-sized upon any of the following conditions: 

□ System restart. 

□ A full dictionary. 

□ If the dictionary size is set manually. 

The re-ranking allows potentially unused dictionaries to be identified and removed, 
freeing resources. 
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You can manually resize an ADN byte-caching dictionary in two places in the Blue Coat 
appliance Management Console: From the Statistics > ADN History > Peer Dictionary Sizing 

tab, or from the Configuration > ADN > Byte Caching tab. You might find the Statistics tab 
easier to use, since you are not required to know the peer ID. Note, however, that only 
peers that are online are displayed in the Statistics tab. If a peer is offline. Configuration > 
ADN > Byte Caching can be used to configure manual dictionary size for any ADN peer. 

To manually resize byte cache dictionaries from the Statistics tab, continue with the next 
section. To manually resize byte cache dictionaries from the ADN tab, skip to "To 
manually resize byte cache dictionaries from the Configuration > ADN > Byte Caching 
tab:" on page 47. 

To manually resize byte cache dictionaries from the Statistics tab: 

1. Select Statistics > ADN History > Peer Dictionary Sizing. 



Peer Dictionary Sizing Inbound Comp. Gain j Outbound Comp. Gain 

- Byte Cache Effectiveness 




[ “ ] 



2. The Peer Dictionary Sizing tab gives you statistics relevant to the byte cache 

dictionary size of all peers on the network. 

• Rank: The value of a peer's dictionary. Manually-configured peers have a higher 
rank than dynamically-configured peers. 

• Peer ID: The serial number of the device. 

• Peer IP: The IP address of the device. 

• Byte Cache Score: The score of this peer relative to other peers. Score is based on 
the value of the dictionary and is used to determine rank. 

• Peer Traffic (GB/Day): The average amount of pre-byte-cache traffic per day. 

• Fill Rate (GB/Day): The average amount of data put into the dictionary per day 
over the last week. 



46 





Chapter 2: Configuring an Application Delivery Network 



Section G: Manually Re-Sizing a Byte-Cache Dictionary 



• Recommended Diet Size (GB): The dictionary size the Blue Coat appliance 
recommends, based on the peer traffic over the last week. 

• Actual Diet Size (GB): The actual size of the dictionary. 

Click anywhere on the line of the device whose dictionary you want to re-size. The 
Edit Peer dialog displays. 

3. To select a dictionary size for the device, select the Manual Re-size radio button and 
enter the value you want in megabytes. 

4. Click OK to have the resizing take effect immediately 

To manually resize byte cache dictionaries from the Configuration > ADN > Byte 
Caching tab: 

1. Select Configuration > ADN > Byte Caching. 



Byte Caching | 




Manual Dictionary Configuration 



Configured Dictionary Size (MB) 



Peer ID 



[ New J | Edit | | Delete | 

2. Click New. The Enable Manual Dictionary Sizing dialog displays. 

3. Enter the peer ID (serial number) of the device with whom you are sharing a 
dictionary. 

4. Enter the new value in megabytes. 

5. Click OK. The peer is added to the manually configured dictionary sizing list and is 
ranked at the top of the dictionary byte cache table. 

Dynamic dictionary sizing is re-enabled through highlighting the peer and selecting 

Delete. 
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Section H: Related CLI Syntax to Configure an ADN Network 

□ To enter configuration mode: 

SGOS# (config) adn 
SGOS# (config adn) 



Note: For detailed information on using these commands, refer to Volume 11: 

Command Line Reference . 



The following subcommands are available: 

SGOS# (config adn) {enable | disable} 

SGOS# (config adn) exit 

SGOS# (config adn) byte-cache 

SGOS# (config adn byte-cache) peer-size peer-id { size_in_megabytes I 

auto} 

SGOS# (config adn byte-cache) exit 
SGOS# (config adn byte-cache) view 
SGOS# (config adn) load-balancing 

SGOS# (config adn load-balancing) 

SGOS# (config adn load-balancing) 

SGOS# (config adn load-balancing) 

SGOS# (config adn load-balancing) 

SGOS# (config adn load-balancing) 
disable } 

SGOS# (config adn load-balancing) 

SGOS# (config adn load-balancing) 

SGOS# (config adn) manager 

SGOS# (config adn manager) 

SGOS# (config adn manager) 

SGOS# (config adn manager) 

SGOS# (config adn manager) 

SGOS# (config adn manager) 

SGOS# (config adn manager) 



{enable | disable} 
exit 

external-vip IP_address 
group group_name 

load-balance-only {enable 



no {external-vip 
view 



I group } 



backup-manager { IPaddress [ID] | self} 
exit 

no {backup-manager | primary-manager} 
port port_number 

primary-manager {IPaddress [ID] \ self} 
secure-port secure_port_number 

view [approved-peers | backup-manager- id 



SGOS# (config adn manager) 

I pending-peers | primary-manager-id] 

SGOS# (config adn manager) approved-peers 

SGOS# (config adn approved-peers) add peer-device-ID 

SGOS# (config adn approved-peers) exit 

SGOS# (config adn approved-peers) remove peer-device-ID 

SGOS# (config adn approved-peers) view 

SGOS# (config adn manager) pending-peers 



{ accept 
{enable 
exit 
view 



I 



reject} 

disable} 



SGOS# (config adn pending-peers) 

SGOS# (config adn pending-peers) 

SGOS# (config adn pending-peers) 

SGOS# (config adn pending-peers) 

SGOS# (config adn) routing 

SGOS# (config adn routing) 

SGOS# (config adn routing) 

SGOS# (config adn routing) 

SGOS# (config adn routing) advertise-internet-gateway 



exit 

prefer- transparent {enable 
view 



disable} 
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SGOS# (config adn routing advertise-internet-gateway) {disable | 
enable } 

SGOS# (config adn routing advertise-internet-gateway) exempt- 
subnet {add { subnet_prefix[/prefix_length] } clear-all | remove 
{ subnet_prefix [ / prefix_length] } | view} 

SGOS# (config adn routing advertise-internet-gateway) exit 
SGOS# (config adn routing advertise-internet-gateway) view 



SGOS# (config adn routing) server- subnets 



SGOS# (config adn routing server-subnets) 
prefix length] 

SGOS# (config adn routing server-subnets) 
SGOS# (config adn routing server-subnets) 
prefix length] 

SGOS# (config adn routing server-subnets) 
SGOS# (config adn routing server-subnets) 



add subnet_prefix [/ 

clear-all 

remove s ubnet_prefix [/ 

exit 

view 



SGOS# (config adn) security 

SGOS# (config adn security) authorization {enable | disable} 

SGOS# (config adn security) device-auth-prof ile profile_name [no- 
authorization] 

SGOS# (config adn security) exit 

SGOS# (config adn security) manager-listening-mode {plain-only | 
plain-read-only | secure-only | both} 

SGOS# (config adn security) no device-auth-prof ile 

SGOS# (config adn security) secure-outbound {none | routing-only | 

secure-proxies | all } 

SGOS# (config adn security) tunnel-listening-mode {plain-only | 
secure-only | both} 

SGOS# (config adn security) view 



SGOS# (config adn) tunnel 



SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
use-local-ip) 

SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 
SGOS# (config adn tunnel) 



connect- transparent {enable | disable} 
exit 

preserve-dest-port {enable | disable} 
port port_number 

proxy-processing http {enable | disable} 
reflect-client-ip (deny | allow | 

secure-port secure_port_number 

tcp-window-size window^size 
view 
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Section I: Policy 

The following gestures can be used for WAN optimization from either the VPM or CPL. 



Note: For more information on using the VPM or CPL to configure policy, refer to 

Volume 6: VPM and Advanced Policy or Volume 10: Content Policy Language Guide. 



□ adn. server (yes I no) (Note that this property overrides all other routing and 
intercept decisions made by ADN based on configuration and routing information.) 

□ adn . server . optimize ( yes | no) 

□ adn . server . optimize . inbound (yes | no) 

□ adn . server . optimize . outbound ( yes | no) 

□ adn . server . optimize . byte-cache ( yes | no) 

□ adn . server . optimize . inbound. byte-cache ( yes | no) 

□ adn . server . optimize . outbound. byte-cache (yes I no) 

□ adn . server . optimize . compress ( yes | no) 

□ adn . server . optimize . inbound. compress ( yes | no) 

□ adn . server . optimize . outbound. compress (yes | no) 

□ adn . server . dscp 
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The SGOS software can reduce the effects of distributed denial of service (DDoS) 
attacks and port scanning, two of the most common virus infections. 

A DDoS attack occurs when a pool of machines that have been infected with a DDoS- 
type of virus attack a specific Web site. As the attack progresses, the target host shows 
decreased responsiveness and often stops responding. Legitimate HTTP traffic is 
unable to proceed because the infected system is waiting for a response from the target 
host. 

Port scanning involves viruses attempting to self-propagate to other machines by 
arbitrarily attempting to connect to other hosts on the Internet. If the randomly selected 
host is unavailable or behind a firewall or does not exist, the infected system continues 
to wait for a response, thus denying legitimate HTTP traffic. 

The SG appliance prevents attacks by limiting the number of simultaneous TCP 
connections from each client IP address and either does not respond to connection 
attempts from a client already at this limit or resets the connection. It also limits 
connections to servers known to be overloaded. 

You can configure attack detection for both clients and servers or server groups, such as 
http:/ / www.bluecoat.com. The client attack-detection configuration is used to control the 
behavior of virus-infected machines behind the SG appliance. The server attack- 
detection configuration is used when an administrator knows ahead of time that a 
virus is set to attack a specific host. 

This feature is only available through the CLI. You cannot use the Management 
Console to enable attack detection. 

This section discusses: 

□ "Configuring Attack-Detection Mode for the Client" on page 53 

□ "Configuring Attack-Detection Mode for a Server or Server Group" on page 57 

Configuring Attack-Detection Mode for the Client 

To enter attack-detection mode for the client: 

From the (config) prompt, enter the following commands: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 

The prompt changes to: 

SGOS# (config client) 

Changing Global Settings 

The following defaults are global settings, used if a client does not have specific limits 
set. They do not need to be changed for each IP address/subnet if they already suit 
your environment: 

□ client limits enabled: true 

□ client interval: 20 minutes 
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□ block-action: drop (for each client) 

□ connection-limit: 100 (for each client) 

□ failure-limit: 50 (for each client) 

□ unblock-time: unlimited 

□ warning-limit: 10 (for each client) 

To change the global defaults: 

Remember that enable/ disable limits and interval affect all clients. The values cannot be 
changed for individual clients. Other limits can be modified on a per-client basis. 



Note: If you edit an existing client's limits to a smaller value, the new value only applies 
to new connections to that client. For example, if the old value was 10 simultaneous 
connections and the new value is 5, existing connections above 5 are not dropped. 



SGOS# (config client) enable-limits | disable-limits 

SGOS# (config client) interval minutes 

SGOS# (config client) block ipaddress [minutes] I unblock ipaddress 
SGOS# (config client) default block-action drop | send-tcp-rst 
SGOS# (config client) default connection-limit 

integer_between_l_and_65535 

SGOS# (config client) default failure-limit integer_between_l_and_500 
SGOS# (config client) default unblock-time minutes_between_10_and_1440 
SGOS# (config client) default warning-limit integer_between_l_and_100 



Table 3-1. Changing Global Defaults 



enable-limits | 
disable -limits 




Toggles between enabled and disabled. The default is disabled. 
This is a global setting and cannot be modified for individual 
clients. 


interval 


integer 


Indicates the amount of time, in multiples of 10 minutes, that 
client activity is monitored. The default is 20. This is a global 
setting and cannot be modified for individual clients. 


block | unblock 


ip address 
[ minutes ] 


Blocks a specific IP address for the number of minutes listed. If 
the optional minutes argument is omitted, the client is blocked 
until explicitly unblocked. Unblock releases a specific IP address. 


default block- 
action 


drop | send- 
tcp-rst 


Indicates the behavior when clients are at the maximum number 
of connections or exceed the warning limit: drop the connections 
that are over the limit or send TCP RST for connections over the 
limit. The default is drop. This limit can be modified on a per- 
client basis. 


default 

connect ion- limit 


integer 


Indicates the number of simultaneous connections between 1 and 
65535. The default is 100. This limit can be modified on a per- 
client basis. 


default failure- 
limit 


integer 


Indicates the maximum number of failed requests a client is 
allowed before the proxy starts issuing warnings. Default is 50. 
This limit can be modified on a per-client basis. 
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default unblock- 
time 


minutes 


Indicates the amount of time a client is blocked at the network 
level when the client-warning-limit is exceeded. Time must be a 
multiple of 10 minutes, up to a maximum of 1440. By default, the 
client is blocked until explicitly unblocked. This limit can be 
modified on a per-client basis. 


default warning- 
limit 


integer 


Indicates the number of warnings sent to the client before the 
client is blocked at the network level and the administrator is 
notified. The default is 10; the maximum is 100. This limit can be 
modified on a per-client basis. 



To create and edit a client IP address: 



Client attack-detection configuration is used to control the behavior of virus-infected 
machines behind the SG appliance. 



1. Verify the system is in the attack-detection client submode. 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) client 
SGOS# (config client) 



2. Create a client. 

SGOS# (config client) create client ip_address or ip_and_length 

3. Move to edit client submode. 



edit client ip address 



SGOS# (config client) 

The prompt changes to: 

SGOS# (config client ipaddress) 

4. Change the client limits as necessary. 

SGOS# (config client ipaddress) 
SGOS# (config client ipaddress) 
integer_between_l_and_65535 
SGOS# (config client ipaddress) 
integer_between 1 and 65535 
SGOS# (config client ipaddress) 
SGOS# (config client ipaddress) 
integer between 1 and 65535 



block-action drop | send-tcp-rst 

connection- limit 

failure -limit 

unblock-time minutes 
warning- limit 



Table 3-2. Changing the Client Limits 



block-action 


drop | send-tcp-rst 


Indicates the behavior when the client is at the maximum 
number of connections: drop the connections that are over the 
limit or send TCP RST for the connection over the limit. The 
default is drop. 


connect ion- limit 


integer 


Indicates the number of simultaneous connections between 1 
and 65535. The default is 100. 


failure-limit 


integer 


Indicates the behavior when the specified client is at the 
maximum number of connections: drop the connections that 
are over the limit or send TCP RST for the connection over the 
limit. The default is 50. 
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Table 3-2. Changing the Client Limits (Continued) 



unblock-time 


minutes 


Indicates the amount of time a client is locked out at the 
network level when the client-warning-limit is exceeded. Time 
must be a multiple of 10 minutes, up to a maximum of 1440. By 
default, the client is blocked until explicitly unblocked. 


warning- limit 


integer 


Indicates the number of warnings sent to the client before the 
client is locked out at the network level and the administrator 
is notified. The default is 10; the maximum is 100. 



To view the specified client configuration: 



Enter the following command from the edit client submode: 



SGOS# (config client ipaddress) 
Client limits for 10.25.36.47: 
Client connection limit: 

Client failure limit: 

Client warning limit: 

Blocked client action: 

Client connection unblock time: 



view 

700 

50 

10 

Drop 

unlimited 



To view the configuration for all clients: 

1. Exit from the edit client submode: 

SGOS# (config client ipaddress) exit 

2. Use the following syntax to view the client configuration: 

view {<Enter> | blocked | connections | statistics} 



To view all settings: 

SGOS# (config client) view <Enter> 

Client limits enabled: true 

Client interval: 20 minutes 



Default client limits: 

Client connection limit: 100 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



Client limits for 10.25.36.47: 

Client connection limit: 700 

Client failure limit: 50 

Client warning limit: 10 

Blocked client action: Drop 

Client connection unblock time: unlimited 



To view the number of simultaneous connections to the SG appliance: 



SGOS# (config 
Client IP 
127 .0.0.1 
10.9.16.112 
10.2.11 .133 



client) view connections 

Connection Count 
1 
1 



1 
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To view the number of blocked clients: 

SGOS# (config client) view blocked 
Client Unblock time 

10.11.12.13 2004-07-09 22 : 03 : 06+00 : 00UTC 

10.9.44.73 Never 

To view client statistics: 

SGOS# (config client) view statistics 

Client IP Failure Count Warning Count 

10.9.44.72 1 0 

To disable attack-detection mode for all clients: 

SGOS# (config client) disable-limits 



Configuring Attack- Detection Mode for a Server or Server Group 

Server attack-detection configuration is used when an administrator knows ahead of time 
that a virus is set to attack a specific host. 

You can create, edit, or delete a server. A server must be created before it can be edited. 
You can treat the server as an individual host or you can add other servers, creating a 
server group. All servers in the group have the same attack-detection parameters, 
meaning that if any server in the group gets the maximum number of simultaneous 
requests, all servers in the group are blocked. 

You must create a server group before you can make changes to the configuration. 



To create a server or server group: 

1. At the (config) prompt: 

SGOS# (config) attack-detection 

SGOS# (config attack-detection) server 

The prompt changes to: 

SGOS# (config server) 

2. Create the first host in a server group, using the fully qualified domain name: 

SGOS# (config server) create hostname 



To edit a server or server group: 

At the (config server) prompt: 

SGOS# (config server) edit hostname 



The prompt changes to (config server hostname) . 



SGOS# (config server hostname ) {add | remove} hostname 

SGOS# (config server hostname ) request-limit integer_from_l_to_65535 



where: 



hostname 




The name of a previously created server or server group. 
When adding a hostname to the group, the hostname does 
not have to be created. The host that was added when 
creating the group cannot be removed. 


add | remove 


hostname 


Adds or removes a server from this server group. 
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request- limit 


integer 


Indicates the number of simultaneous requests allowed from 






this server or server group. The default is 1000. 



To view the server or server group configuration: 

SGOS# (config server hostname) view 
Server limits for hostname: 

Request limit: 1500 
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This chapter describes how to configure the SG appliance to join peer clusters that 
process requests in asymmetrically routed networks. 



It is common in larger enterprises to have multiple SG appliances residing on different 
network segments; for example, the enterprise receives Internet connectivity from more 
than one ISP. If IP spoofing is enabled, connection errors can occur because the SG 
appliance terminates client connections and makes a new outbound connection (with 
the source IP address of the client) to the server. The response might not return to the 
originating SG appliance, as illustrated in the following diagram. 



Flow: 

1: The client makes a request; SG appliance 1 (SG 1) intercepts the connection. 

2. SG 1 terminates the client connection and invokes an oubound connection to the server 
(with the source IP address of the client). 

3. Based on its internal routing policies, the server believes ISP 2 provides a viable path back to 
the client. 

4. SG 2 intercepts the response with the originating client IP address; however, it does not 
recognize the connection from the client and attempts to reset the connection. 

5. The client connection ultimately times out and the client receives connection timeout error. 

Figure 4-1 . Multiple SG appliances in an asymmetric routing environment 



About Asymmetric Routing Environments 




i 
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The TCP Connection Forwarding Solution 

Enabling TCP Connection Forwarding is a critical component of the following solutions: 

□ "About Bidirectional Asymmetric Routing" on page 60. 

□ "About Dynamic Load Balancing" on page 61. 

□ "About ADN Transparent Tunnel Load Balancing" on page 61. 

About Bidirectional Asymmetric Routing 

To solve the asymmetric routing problem, at least one SG appliance on each network 
segment must be configured to perform the functionality of an L4 switch. These selected 
appliances form a cluster. With this peering relationship, the connection responses are 
able to be routed to the network segment where the originating client resides. 

In the 5.1.4.x release, cluster membership is manual; that is, SG appliances must be added 
to a cluster by enabling connection forwarding and adding a list of other peers in the 
cluster. After a peer joins a cluster, it begins sending and receiving TCP connections, and 
notifies the other peers about its connection requests. 




m 



Flow: 

1 : The client makes a request; SG appliance 1 (SG 1 ) intercepts the connection. 

2: Because SG 1 and SG 2 are peers in the TCP forwarding cluster, SG 1 informs SG 2 
about the connection request. 

3: SG 1 terminates the client connection and invokes an oubound connection to the server 
(with the source IP address of the client). 

4 Based on its internal routing policies, the server believes ISP 2 provides a viable path 
back to the client. 

5: SG 2 intercepts the response with the originating client IP address. 

6: SG 2 routes the response back up to the internal network. 

7: SG 1 receives the response and serves the client. 

Figure 4-2. SG appliances share TCP connection information 
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About Dynamic Load Balancing 

In a deployment where one SG appliance receives all of the traffic originating from clients 
and servers from an external routing device and distributes connections to other SG 
appliances, TCP connection forwarding enables all of the appliances to share connection 
information (for each new connection) and the in-line SG appliance routes the request 
back to the originating appliance, thus lightening the load on the inline appliance. 




In the above network topography, SG appliance SG 1 is deployed inline to receive all 
traffic (by way of a switch) originating from the clients to the servers and servers to the 
clients and serves as a load balancer to the other four SG appliances. Appliances 2 through 
5 also have independent connectivity to the clients and the servers. When all appliances 
belong to the same peering cluster and have connection forwarding enabled, appliance SG 
1 knows which of the other appliances made a specific connection and routes the response 
to that appliance. 

In this deployment, a TCP acknowledgement is sent and retransmitted, if required, to 
ensure the information gets there, but each new connection message is not explicitly 
acknowledged. However, if the SG appliance receives packets for a connection that is 
unrecognized, the appliance retains those packets for a short time before deciding 
whether to forward or drop them, which allows time for a new connection message from a 
peer to arrive. 

While adding more peers to a cluster increases the connection synchronization traffic, the 
added processing power all but negates that increase. You can have multiple peer clusters, 
and if you are cognoscente of traffic patterns to and from each cluster, you can create an 
effective cluster strategy. The only limitation is that an SG appliance can only be a peer in 
one cluster. 

The Blue Coat load balancing solution is discussed in greater detail in earlier sections of 
this chapter. 

About ADN Transparent Tunnel Load Balancing 

TCP connection forwarding is a critical component of the Blue Coat ADN transparent 
tunnel load balancing deployment. Achieving efficient load balancing is difficult when 
ADN transparent tunneling is employed and an external load balancer is distributing 
requests to multiple SG appliances. 
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A user-noticeable performance degradation occurs if the router, switch, or load balancer 
sends traffic to an SG appliance that has not been servicing a particular client long enough 
to build up substantial byte caching dictionary, thus the compression ratio is low. When 
the SG appliances connected to the routing device belong to the same peer cluster and 
connection forwarding is enabled, the ADN managers on each appliance know which of 
their peers has the best byte caching dictionary with the client and forwards the request. 
This is illustrated in the following diagram. 





Client 3 



Flow: 

1 : Client 3 in a branch office makes another in a series of requests to a server at a corporate location. 

2. The load balancer forwards a series of requests to SG appliance SG 2. 

3. SG 2 has been servicing Client 3 and the ADN manager has built up a substantial compression ratio 
with the ADN manager with SG 4 at the corporate location. 

4. SG 4 at the corporate location contacts the server and sends the response that it receives from the 
server. 

5. The load balancer sends the next request to SG 3. 

6. SG 3 knows SG 2 has a better compression ratio with this client, and the ADN manager forwards the 
request over to SG 2. 



Figure 4-4. ADN Transparent Tunnel load balancing with Connection Forwarding enabled 



Load balancing is based on the IP address of the remote ADN peer. This assures that all 
the traffic from a particular ADN peer to the local ADN cluster always goes to a specific 
local SG appliance, thus eliminating the inefficiency of keeping dictionaries for that 
remote peer on more than one local SG appliance. 

The Blue Coat ADN solution is discussed in greater detail in Chapter 2: "Configuring an 
Application Delivery Network" on page 13. 
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TCP Configuration Forwarding Deployment Notes 

When configuring your network for TCP connection forwarding, consider the following: 

□ Peers can be added to clusters at any time without affecting the performance of the 
other peers. An SG appliance that joins a peer cluster immediately contacts every other 
peer in the cluster. Likewise, a peer can leave a cluster at anytime. This might be a 
manual drop or a forced drop because of a hardware or software failure. If this 
happens, the other peers in the cluster continue to process connection forwarding 
requests. 

□ Connections between peers are not encrypted and not authenticated. If you do not 
assign the correct local IP address on an SG appliance with multiple IP addresses, 
traffic sent peer to peer might be routed through the Internet, not the intranet, 
exposing your company-sensitive data. 

□ The peering port — the connection between SG appliance connection forwarding 
peers — cannot be configured with bypass services. This means an SG appliance cannot 
be deployed in transparent mode between two SG appliances that are peers. 

□ SG does not enforce a maximum number of appliances a peer cluster supports, but 
currently the deployment is designed to function with up to 20 SG appliances. 

□ Because TCP connection forwarding must function across different network segments, 
employing multicasting, even among SG appliance peers on the same network, is not 
supported. 

□ There might be a slight overall performance impact from enabling TCP connection 
forwarding, especially in deployments where traffic is largely already being routed to 
the correct SG appliance. If a substantial amount of traffic requires forwarding, the 
performance hit is equitable to processing the same amount of bridging traffic. 

Configuring TCP Connection Forwarding 

As described in the previous concept sections, enabling TCP connection forwarding 
provides one component to a larger deployment solution. After you have deployed Blue 
Coat appliances into the network topography that best fits your enterprise requirements, 
enable TCP connection forwarding on each Blue Coat appliance that is to belong to the 
peering cluster, and add the IP address of the other peers. The peer lists on nil of the 
cluster members must be the same, and an SG appliance cannot have a different local peer 
IP address than what is listed in another peers list. A peer list can contain only one local IP 
address. 

To enable TCP Connection Forwarding: 

1. Select Configuration > Network > Advanced > Connection Forwarding. 
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WCCP | VIPs | Failover Connection Forwarding 



-o @ Enable Connection Forwarding 
Local IP: 10.9.59.246 v 

Port: 3030 





2. From the Local IP drop-down list, select the IP address that is routing traffic to this SG 
appliance. 

Specify the port number (the default is 3030 ) that the SG appliance uses to 
communicate with all peers, which includes listening and sending out connection 
forwarding cluster control messages to all peers in the group. All peers in the group 
must use the same port number (when connection forwarding is enabled, you cannot 
change the port number). 

3. Add the cluster peers: 

a. Click Add. 

b. In the Peer IPs field, enter the IP addresses of the other peers in the cluster 
that this SG appliance is to communicate connection requests with.; click OK. 

4. Select Enable Connection Forwarding. 

5. Click Apply. 

This SG appliance joins the peer cluster and immediately begins communicating with its 
peers. 

Copying Peers to Another SG Appliance in the Cluster 

If you have a larger cluster that contains several peer IP addresses, select all of the IP 
addresses in the Connection Forwarding Peer IPs list and click Copy To Clipboard; this 
action includes the local IP address of the peer you are copying from, and it will be 
correctly added as a remote peer IP address on the next appliance. When you configure 
connection forwarding on the next appliance, click Paste From Clipboard to paste the list of 
peers, and click Apply. Whichever peer IP address is the new appliance's local IP address 
is pulled out of the list and used as the local IP address on the new appliance. If a local IP 
address is not found or if more than one local IP address is found, the paste fails with an 
error. 
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Removing a Peer 

A network change or other event might require you to remove a peer from the cluster. 
Highlight a peer IP address and click Remove. The peer connection is terminated and all 
connections associated with the peer are removed from the local system. 



Note: A CLI command is available that allows you to disable a peer, which terminates 
the communication with other peers, but does not remove the peer from the cluster. See 
the next section. 



Related CLI Syntax to Configure TCP Connection Forwarding 



□ To enter configuration mode: 

SGOS# (config) connection- forwarding 



□ The following subcommands are available: 



SGOS# 

SGOS# 

SGOS# 

SGOS# 

SGOS# 



(config 

(config 

(config 

(config 

(config 



connection 

connection 

connection 

connection 

connection 



forwarding) 

forwarding) 

forwarding) 

forwarding) 

forwarding) 



add ipaddress 
port number 
[enable | disable] 

[clear | remove ip_address] 

[view | exit] 



□ The following configuration and statistics commands are available: 

SGOS# show connection- forwarding configuration 
SGOS# show connection- forwarding statistics 
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Bandwidth management (BWM) allows you to classify, control, and limit the amount of 
bandwidth used by different classes of network traffic flowing into or out of the SG 
appliance. Network resource sharing (or link sharing) is accomplished by using a 
bandwidth-management hierarchy where multiple traffic classes share available 
bandwidth in a controlled manner. 



Note: The SG appliance does not attempt to reserve any bandwidth on the network 
links that it is attached to or otherwise guarantee that the available bandwidth on the 
network can sustain any of the bandwidth limits which have been configured on it. The 
SG appliance can only shape the various traffic flows passing through it, and prioritize 
some flows over others according to its configuration. 



By managing the bandwidth of specified classes of network traffic, you can accomplish 

the following: 

□ Guarantee that certain traffic classes receive a specified minimum amount of 
available bandwidth. 

□ Limit certain traffic classes to a specified maximum amount of bandwidth. 

□ Prioritize certain traffic classes to determine which classes have priority over 
available bandwidth. 

Bandwidth Management Overview 

To manage the bandwidth of different types of traffic that flow into, out of, or through 

the SG appliance, you must do the following: 

□ Determine how many bandwidth classes you need and how to configure them to 
accomplish your bandwidth management goals. This includes determining the 
structure of one or more bandwidth hierarchies if you want to use priority levels to 
manage bandwidth. 

□ Create and configure bandwidth classes accordingly. 

□ Create policy rules using those bandwidth classes to identify and classify the traffic 
in the SG appliance. 

□ Enable bandwidth management. 

Bandwidth management configuration consists of two areas: 

□ Bandwidth allocation 

This is the process of creating and configuring bandwidth classes and placing them 
into a bandwidth class hierarchy. This process can be done using either the 
Management Console or the CLI. 
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□ Flow classification 

This is the process of classifying traffic flows into bandwidth management classes 
using policy rules. Policy rules can classify flows based on any criteria testable by 
policy You can create policy rules using either the Visual Policy Manager (VPM), 
which is accessible through the Management Console, or by composing Content 
Policy Language (CPL). 



Note: For more information about using VPM to create policy rules, refer to Volume 6: 
VPM and Advanced Policy. For information about composing CPL, refer to Volume 10: 
Content Policy Language Giude. 



Allocating Bandwidth 

The process of defining bandwidth classes and grouping them into a bandwidth class 
hierarchy is called bandwidth allocation. Bandwidth allocation is based on: 

□ the placement of classes in a hierarchy (the parent/ child relationships). 

□ the priority level of classes in the same hierarchy. 

□ the minimum and / or maximum bandwidth setting of each class. 

For example deployment scenarios, see "Bandwidth Allocation and VPM Examples" on 
page 78. 

Bandwidth Classes 

To define a bandwidth class, you create the class, giving it a name meaningful to the 
purpose for which you are creating it. You can configure the class as you create it or edit it 
later. The available configuration settings are: 

□ Parent: Used to create a bandwidth-management hierarchy. 

□ Minimum Bandwidth: Minimum amount of bandwidth guaranteed for traffic in this 
class. 

□ Maximum Bandwidth: Maximum amount of bandwidth allowed for traffic in this 
class. 

□ Priority: Relative priority level among classes in the same hierarchy. 

Parent Class 

A parent class is a class that has children. When you create or configure a bandwidth class, 
you can specify another class to be its parent (the parent class must already exist). Both 
classes are now part of the same bandwidth-class hierarchy, and so are subject to the 
hierarchy rules (see "Class Flierarchy Rules and Restrictions" on page 70). 

Minimum Bandwidth 

Setting a minimum for a bandwidth class guarantees that class receives at least that 
amount of bandwidth, if the bandwidth is available. If multiple hierarchies are competing 
for the same available bandwidth, or if the available bandwidth is not enough to cover the 
minimum, bandwidth management is not be able to guarantee the minimums defined for 
each class. 
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Note: The SG appliance does not attempt to reserve any bandwidth on the network links 
that it is attached to or otherwise guarantee that the available bandwidth on the network 
can be used to satisfy bandwidth class minimums. The SG appliance can only shape the 
various traffic flows passing through it, and prioritize some flows over others according 
to its configuration. 



Maximum Bandwidth 

Setting a maximum for a bandwidth class puts a limit on how much bandwidth is 
available to that class. It does not matter how much bandwidth is available; a class can 
never receive more bandwidth than its maximum. 

To prevent a bandwidth class from using more than its maximum, the SG appliance inserts 
delays before sending packets associated with that class until the bandwidth used is no 
more than the specified maximum. This results in queues of packets (one per class) 
waiting to be sent. These queues allow the SG appliance to use priority settings to 
determine which packet is sent next. If no maximum bandwidth is set, every packet is sent 
as soon as it arrives, so no queue is built and nothing can be prioritized. 

Unlike minimums and priority levels, the maximum-bandwidth setting can purposely 
slow down traffic. Unused bandwidth can go to waste with the maximum-bandwidth 
setting, while the minimum-bandwidth settings and priority levels always distributes any 
unused bandwidth as long as classes request it. However, priority levels are not 
meaningful without a maximum somewhere in the hierarchy. If a hierarchy has no 
maximums, any class in the hierarchy can request and receive any amount of bandwidth 
regardless of its priority level. 

Priority 

When sharing excess bandwidth with classes in the same hierarchy, the class with the 
highest priority gets the first opportunity to use excess bandwidth. When the high- 
priority class uses all the bandwidth it needs or is allowed, the next class gets to use the 
bandwidth, if any remains. If two classes in the same hierarchy have the same priority, 
then excess bandwidth is shared in proportion to their maximum bandwidth setting. 

Class Hierarchies 

Bandwidth classes can be grouped together to form a class hierarchy. Creating a 
bandwidth class allows you to allocate a certain portion of the available bandwidth to a 
particular type of traffic. Putting that class into a bandwidth-class hierarchy with other 
bandwidth classes allows you to specify the relationship among various bandwidth 
classes for sharing available (unused) bandwidth. 

The way bandwidth classes are grouped into the bandwidth hierarchy determines how 
they share available bandwidth among themselves. You create a hierarchy so that a set of 
traffic classes can share unused bandwidth. The hierarchy starts with a bandwidth class 
you create to be the top-level parent. Then you can create other bandwidth classes to be 
the children of the parent class, and those children can have children of their own. 

To manage the bandwidth for any of these classes, some parent in the hierarchy must have 
a maximum bandwidth setting. The classes below that parent can then be configured with 
minimums and priority levels to determine how unused bandwidth is shared among 
them. If none of the higher level classes have a maximum bandwidth value set, then 
bandwidth flows from the parent to the child classes without limit. In that case, 
minimums and priority levels are meaningless, because all classes get all the bandwidth 
they need at all times. The bandwidth, in other words, is not being managed. 
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Class Hierarchy Rules and Restrictions 

Certain rules and restrictions must be followed to create a valid BWM class hierarchy: 

□ Each traffic flow can only belong to one bandwidth management class. 

You can classify multiple flows into the same bandwidth class, but any given flow is 
always counted as belonging to a single class. If multiple policy rules match a single 
flow and attempt to classify it into multiple bandwidth classes, the last classification 
done by policy applies. 

□ When a flow is classified as belonging to a bandwidth class, all packets belonging to 
that flow are counted against that bandwidth class. 

□ If a minimum bandwidth is configured for a parent class, it must be greater than or 
equal to the sum of the minimum bandwidths of its children. 

□ If a maximum bandwidth is configured for a parent class, it must be greater than or 
equal to the largest maximum bandwidth set on any of its children. It must also be 
greater than the sum of the minimum bandwidths of all of its children. 

□ The minimum bandwidth available to traffic directly classified to a parent class is 
equal to its assigned minimum bandwidth minus the minimum bandwidths of its 
children. For example, if a parent class has a minimum bandwidth of 600 kbps and 
each of its two children have minimums of 300 kbps, the minimum bandwidth 
available to traffic directly classified into the parent class is 0. 

Relationship among Minimum, Maximum, and Priority Values 

Maximum values can be used to manage bandwidth for classes whether or not they are 
placed into a hierarchy. This is not true for minimums and priorities, which can only 
manage bandwidth for classes that are placed into a hierarchy. Additionally, a hierarchy 
must have a maximum configured on a high-level parent class for the minimums and 
priorities to manage bandwidth. 

This is because, without a maximum, bandwidth goes to classes without limit and there is 
no point to setting priorities or minimum guarantees. Bandwidth cannot be managed 
unless a maximum limit is set somewhere in the hierarchy. 

When a hierarchy has a maximum on the top-level parent and minimums, maximums and 
priorities placed on the classes related to that parent, the following conditions apply: 

□ If classes in a hierarchy have minimums, the first thing that happens with available 
bandwidth is that all the minimum requests are satisfied. If the amount requested is 
less than the minimum for any class, it receives the entire amount, and its priority level 
does not matter. 

Even though a minimum is considered to be a guaranteed amount of bandwidth, 
satisfying minimums is dependent on the parent being able to receive its own 
maximum, which is not guaranteed. 

□ When all of the classes in a hierarchy have had their minimums satisfied, any 
additional requests for bandwidth must be obtained. When a class requests more than 
its minimum, it must obtain bandwidth from its parent or one of its siblings. If, 
however, a class requests more than its maximum, that request is denied — no class 
with a specified maximum is ever allowed more than that amount. 

□ If a class does not have a minimum specified, it must obtain all of the bandwidth it 
requests from its parents or siblings, and it cannot receive any bandwidth unless all of 
the minimums specified in the other classes in its hierarchy are satisfied. 
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□ Classes obtain bandwidth from their parents or siblings based on their priority 

levels — the highest priority class gets to obtain what it needs first, until either its entire 
requested bandwidth is satisfied or until it reaches its maximum. After that, the next 
highest priority class gets to obtain bandwidth, and this continues until either all the 
classes have obtained what they can or until the maximum bandwidth available to the 
parent has been reached. The amount available to the parent can sometimes be less 
than its maximum, because the parent must also participate in obtaining bandwidth in 
this way with its own siblings and/or parent if it is not a top-level class. 

Flow Classification 

You can classify flows to BWM classes by writing policy rules that specify the bandwidth 

class that a particular traffic flow belongs to. A typical transaction has four traffic flows: 

1. Client inbound — Traffic flowing into the SG appliance from a client (the entity sending 
a request, such as a client at a remote office linked to the appliance). 

2. Server outbound — Traffic flowing out of the SG appliance to a server. 

3. Server inbound — Traffic flowing back into the SG appliance from a server (the entity 
responding to the request). 

4. Client outbound — Traffic flowing back out of the SG appliance to a client. 

The figure below shows the traffic flows between a client and server through the SG 

appliance. 



Orient Inbound 




^ Server Outbound 



Client 



Q Client Outbound 



@ Server Inbound 




Some types of traffic can flow in all four directions. The following example describes 
different scenarios that you might see with an HTTP request. A client sends a GET to the 
SG appliance (client inbound). The SG appliance then forwards this GET to a server (server 
outbound). The server responds to the SG appliance with the appropriate content (server 
inbound), and then the appliance delivers this content to the client (client outbound). 



Policy allows you to configure different classes for each of the four traffic flows. See 
"Using Policy to Manage Bandwidth" on page 77 for information about classifying traffic 
flows with policy. 



Configuring Bandwidth Allocation 

You can use either the Management Console or the CLI to do the following tasks: 

□ Enable or disable bandwidth management. 

□ Create and configure bandwidth classes. 
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□ Delete bandwidth classes. 

□ View bandwidth management class configurations. 

Note: If you plan to manage the bandwidth of streaming media protocols (Windows 
Media, Real Media, or QuickTime), you might want to use the streaming features instead 
of the bandwidth management features described in this section. For most circumstances. 
Blue Coat recommends that you use the streaming features to control streaming 
bandwidth rather than the bandwidth management features. For information about the 
differences between these two methods, refer to Volume 3: Web Communication Proxies. 



Enabling Bandwidth Management 

The following procedures explain how to enable or disable bandwidth management. 

To enable bandwidth management: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 




3. Click Apply to commit the changes to the SG appliance. 



Creating, Editing, and Deleting Bandwidth Classes 

The following procedure details how to create bandwidth management class. 



To create a BWM class: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 



Bandwidth Classes 

E/1 Enable Bandwidth Management 
rBandwidth Classes 



An existing 
parent class 



Bandwidth Class 
♦ ParentA 



Min(kbps) Max(kbps) Priority 

unspecified unlimited 



Create Bandwidth Class 




1 A /d/d 1 








Class Name 


ChildA 


< 


Parent 


ParentA 


v< 


| | Min. Bandwidth 




- 


0 Max. Bandwidth 


750 


<i 


Priority 




WEb 



OK 



Cancel 




2. To create a new BWM class, click New. 
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3. Fill in the fields as appropriate: 

a. Class name: Assign a meaningful name for this class. The name can be up to 
64 characters long; spaces are not allowed. 

b. Parent: (Optional) To assign the class as a child of another parent class in the 
bandwidth class hierarchy, select an existing parent class from the drop-down 
list. 

c. Min. Bandwidth: (Optional) Select Min. Bandwidth and enter a minimum 
bandwidth value in the field (kilobits per second (kbps)). The default 
minimum bandwidth setting is unspecified, meaning the class is not 
guaranteed a minimum amount of bandwidth. 

d. Max. Bandwidth: (Optional) Select Max. Bandwidth and enter a maximum 
bandwidth value in the field. The default maximum bandwidth setting is 
unlimited, meaning the class is not limited to a maximum bandwidth value by 
this setting. 

e. Priority: Select a priority level for this class from the Priority drop-down list — 
0 is the lowest priority level and 7 is the highest. The default priority is 0. 

4. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 

[-Bandwidth Classes — 

Bandwidth Class Min(kbps) Max(kbps) Priority 



ParentA unspecified unlimited 



♦ ChildA unspecified 750 4 

Figure 5-1 . A child bandwidth management class added to a parent class. 

After you add a child class to a parent class, the parent class is denoted by a folder icon. 
Double-click the folder to view all of the child classes under that parent. 

To edit a BWM class: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

2. Highlight the class and click Edit. 

3. Edit the fields as appropriate. 

To delete a BWM class: 



Note: You cannot delete a class that is referenced by another class or by the currently 
installed policy. For instance, you cannot delete a class that is the parent of another class 
or one that is used in an installed policy rule. If you attempt to do so, a message displays 
explaining why this class cannot be deleted. 



1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

2. Highlight the class to delete and Delete. 

3. Click Yes to delete the class. 

4. Click Apply. 



Viewing Bandwidth Management Configurations 

You can view the following bandwidth class configurations: 

□ Level in the hierarchy (parent /child relationships) 
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□ Priority level 

□ Maximum bandwidth value 

□ Minimum bandwidth value 

To view BWM configuration: 

1. Select Configuration > Bandwidth Management > BWM Classes > Bandwidth Classes. 

On this tab, you can view a class's minimum, maximum and priority value. Top level 
classes are visible — classes with children have a folder icon on the left. 

2. To view the configurations of the child class(es) of a class, double-click the folder icon. 
The child classes become visible. A second double-click closes the folder. 

Related CLI Syntax to Configure Bandwidth Management 

□ To enter configuration mode: 

SGOS# (config) bandwidth-management 

□ The following subcommands are available: 

SGOS# (config bandwidth-management) enable | disable 

SGOS# (config bandwidth-management) create | delete bwm__class 

□ To enter edit mode: 

SGOS# (config bandwidth-management) edit bwm_class 

□ The following subcommands are available: 

SGOS# (config bw-class bwm_class) min-bandwidth minimum_in_kbps 
SGOS# (config bw-class bwm_class) max-bandwidth maximum_in_kbps 
SGOS# (config bw-class bwm_class) priority value_from_0_to_7 
bandwidth-management bwm^class) no {min-bandwidth | max-bandwidth} 

SGOS# (config bandwidth-management bwm__class) parent parent_class^name 

-or- 

SGOS# (config bandwidth-management bwm__class) no parent 
SGOS# (config bandwidth-management bwm__class) view 

Bandwidth Management Statistics 

The bandwidth management statistics tabs (Current Class Statistics and Total Class 
Statistics) display the current packet rate and total number of packets served, the current 
bandwidth rate, and the total number of bytes served and packets dropped. 

Current Class Statistics Tab 

The Current Class Statistics tab displays the following information for each bandwidth 
class: 

□ Current Packet Rate: current packets-per-second (pps) value. 

□ Current Bandwidth: current bandwidth in kilobits per second (Kbps). 

To view current bandwidth management class statistics: 

1. Select Statistics > Bandwidth Management > Current Class Statistics. 

The high level bandwidth classes and their statistics are visible. 
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Current Class Statistics Total Class Statistics 



rBandwidth Classes- 



Bandwidth Class 


| Current Packet Rate(pps) | 


Current Bandwidth(kbps) | 


• bridging 


0 


0 


• ftp 


D 


0 


• http 


0 


0 


• im 


0 


0 


_| streaming 


0 


0 


• P2P 


0 


0 


• service-info 


0 


0 


• socks 


0 


0 


• tcp-tunnel 


0 


0 



Help 



2. To view the statistics of child bandwidth classes, double-click the folder icon of the 
parent class. 

The child classes become visible. A second double-click closes the folder. 

Total Class Statistics Tab 

The Total Class Statistics tab displays the following information for each bandwidth class: 

□ Packets: the total number of packets served. 

□ Bytes: the total number of bytes served. 

□ Drops: the total number of packets dropped. 

To view total bandwidth management class statistics: 

1. Select Statistics > Bandwidth Management > Total Class Statistics. 

The high level bandwidth classes and their statistics are visible. 



Current Class Statistics Total Class Statistics 

rBandwidth Classes 




Help 
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2. To view the statistics of child bandwidth classes, double-click the folder icon of the 
parent class. A second double-click closes the folder. 



Bandwidth Management Statistics in the CLI 



To view bandwidth management statistics: 

1. To view all bandwidth management statistics, enter the following commands at the 
prompt: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) view statistics 

2. To view the BWM statistics for a specific class, enter the following command at the 
(config) command prompt: 

SGOS# (config bandwidth-management) view statistics bwm_class 



Example 



SGOS# (config bandwidth-management) 


Class Name: 


http 


Parent : 


<none> 


Minimum Bandwidth: 


unspecified 


Maximum Bandwidth: 


unlimited 


Priority: 


0 




Total Bytes: 


0 


bytes 


Total Packets: 


0 


pkts 


Dropped Packets: 


0 


pkts 


Current Bandwidth: 


0 


kbps 


Current Packet Rate: 


0 


pps 


Queue Length: 


0 


bytes 



view statistics http 



Parent 


The class name of the parent of this class. 


Minimum Bandwidth 


The maximum bandwidth setting for this class. 


Maximum Bandwidth 


The minimum bandwidth setting for this class. 


Priority 


The priority level for this class. 


Total Bytes 


The total number of bytes served. 


Total Packets 


The total number of packets served. 


Dropped Packets 


Total number of packets dropped (packets in the queue that are 
dropped because the queue length is reached). 


Current Bandwidth 


Current bandwidth value (in kilobits per second). 


Current Packet Rate 


Current packets-per-second value. 


Queue Length 


Maximum length allowed for the queue of packets that lack 
available bandwidth but are waiting for bandwidth to become 
available. 



To clear bandwidth management statistics: 

1. To clear bandwidth management statistics for all bandwidth management classes, 
enter the following command at the prompt: 

SGOS# clear-statistics bandwidth-management 
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2. To clear bandwidth management statistics for a particular class, enter the following 
command at the prompt: 

SGOS# clear-statistics bandwidth-management class bandwidth_class_name 

Using Policy to Manage Bandwidth 

After creating and configuring bandwidth management classes, create policy rules to 
classify traffic flows using those classes. Each policy rule can only apply to one of four 
traffic flow types: 

□ Client inbound 

□ Client outbound 

□ Server inbound 

□ Server outbound 

You can use the same bandwidth management classes in different policy rules; one class 
can manage bandwidth for several types of flows based on different criteria. However, 
any given flow is always be counted as belonging to a single class. If multiple policy rules 
match a flow and try to classify it into multiple bandwidth classes, the last classification 
done by policy applies. 

To manage the bandwidth classes you have created, you can either compose CPL (see 
"CPL Support for Bandwidth Management" on page 77 below) or you can use VPM (see 
"VPM Support for Bandwidth Management" on page 78). To see examples of policy using 
these methods, see "Bandwidth Allocation and VPM Examples" on page 78 or "Policy 
Examples: CPL" on page 85. 

CPL Support for Bandwidth Management 

You must use policy to classify traffic flows to different bandwidth classes. Refer to 
Volume 10: Content Policy Language Guide for more information about writing and 
managing policy. 

CPL Triggers 

You can use all of the CPL triggers for BWM classification (refer to Volume 10: Content 
Policy Language Guide for information about using CPL triggers). Basing a bandwidth 
decision on a trigger means that the decision does not take effect until after the 
information needed to make that decision becomes available. For example, if you set the 
CPL to trigger on the MIME type of the HTTP response, then the HTTP headers must be 
retrieved from the OCS before a classification can occur. The decision to retrieve those 
headers occurs too late to count any of the request bytes from the client or the bytes in the 
HTTP response headers. However, the decision affects the bytes in the body of the HTTP 
response and any bytes sent back to the client. 

Supported CPL 

Bandwidth class can be set with policy on each of these four traffic flows: 

□ limitjbandwidth. client. inbound(none | bwm_class) 

□ limit_bandwidth.client.outbound(none | bwmjclass) 

□ limit_bandwidth.server.inbound(none | bwmjclass) 

□ limit_bandwidth.server.outbound(none | bwmjclass) 

If you set policy to none, the traffic is unclassified and is not to be bandwidth-managed. 
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VPM Support for Bandwidth Management 

You can manage bandwidth using VPM in the Action column of four policy layers: Web 
Access, DNS Access, Web Content, and Forwarding Layers. For more information about 
using VPM to manage bandwidth, refer to Volume 6: VPM and Advanced Policy. For 
examples of bandwidth management scenarios using VPM, see "Bandwidth Allocation 
and VPM Examples" below. 

Bandwidth Allocation and VPM Examples 

This section illustrates how to use the VPM to allocate bandwidth, arrange hierarchies, 
and create policy. It describes an example deployment scenario and the tasks an 
administrator must accomplish to manage the bandwidth for this deployment. For 
specific instructions about allocating bandwidth, see "Configuring Bandwidth 
Allocation" on page 71. For examples of CPL bandwidth management tasks, see "Policy 
Examples: CPL" on page 85. 

Task One: Bandwidth Allocation 

The administrator is responsible for managing the bandwidth of three branch offices. He 
was told to ensure that each office uses no more than half of its total link bandwidth for 
Web and FTP traffic. The total link bandwidth of each office is as follows: 

□ Office A: 1.5 Mb 

□ Office B: 1 Mb 

□ Office C: 2 Mb 

He creates one bandwidth class for each of the three offices and configures the maximum 
bandwidth to an amount equal to half of the total link bandwidth of each, as shown 
below. He also creates policy rules for each class, as described below in "Task One: VPM". 




Each of the classes above has a maximum set at an amount equal to half of the total link 
bandwidth for each office. A hierarchy does not exist in this scenario. 



Task One: VPM 

The administrator has created one bandwidth class for each office, setting a maximum 
bandwidth on each one equal to the half of the total link bandwidth of each. Now he must 
create policy rules to classify the traffic flows. 
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FTP/HTTP Limitations 



Destination 

ll£ 



Service 

Any 



Time 

lAnv 



Action Track 

fa Denv iNone 







Add 



Close 



Help 



The administrator launches the VPM and creates a new Web Access Layer, naming it FTP/ 
HTTP Limitations. He selects the Client IP Address/Subnet object in the Source column, 
filling in the IP address and mask of the subnet used by 0ffice_A. 




^ Virus Detected 



He selects a Combined Service Object in the Service column, naming it FTP/HTTP and 

adding a Client Protocol for FTP and for HTTP 
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He adds both protocols to the At least one of these objects field. 




In the Action column, he selects Manage Bandwidth, naming it Office_A and setting it to 
manage the bandwidth of Office_A on the Client side in the Outbound direction. 

He adds two more similar rules for the other two offices. He is able to reuse the same 
Combined Service Object in the Service column, but must add new objects specific to each 
office in the Source and Action columns. The order of the rules does not matter here, 
because each office, and thus each rule, is distinct because of its IP address/ subnet mask 
configuration. 

Task Two: Bandwidth Allocation 

A few days later, the administrator gets a visit from the CEO of his company. She wants 
him to fix it so that she can visit any of the branch offices without having her own Web 
and FTP access slowed down unnecessarily. 

The administrator creates two more classes for each office: one for the CEO and another 
for everyone else (employees). He sets the parent class of each new class to the 
appropriate class that he created in Task One. For example, he creates Emp_A and CEO_A 
and sets their parent class to Office_A. He also sets a priority level for each class: 0 (the 
lowest) for employees and 1 for the CEO. He then uses VPM to create additional policy 
rules for the new classes (see "Task Two: VPM" below). This figure shows the hierarchical 
relationship among all of the classes. 
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The administrator now has three separate hierarchies. In each one, bandwidth is limited 
by the configuration of the parent class, and the two child classes are prioritized to 
determine how they share any unused bandwidth. Because no minimums have been set, 
the highest priority class has the first opportunity to use all of the available bandwidth; 
whatever is left then goes to the next priority class. 

Priority levels are only effective among the classes in the same hierarchy. This means that 
the priority levels for the Office_A hierarchy do not affect the classes in the Office_B or 
Office_C hierarchies. 

Task Two: VPM 

Because the CEO wants to prioritize FTP and HTTP access among employees and herself, 
the administrator must create additional bandwidth classes (as described above in "Task 
Two: Bandwidth Allocation") and write policy rules to classify the traffic for the new 
classes. 




He first edits each of the three VPM rules for the three offices. He edits each the Manage 
Bandwidth objects, changing the name of the objects to Emp_A, Emp_B, and Emp_C and 
changes the bandwidth class to the corresponding employee class. 
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Next, he creates three more rules for the CEO, moving them above the first three rules. For 
the CEO rules, he selects the same combined FTP/HTTP object in the Service column; in the 
Action column, he selects a Manage Bandwidth object configured for client side/ outbound, 
as before, but this time, he names the objects CEO_A, CEO_B, and CEO_C and selects the 
corresponding CEO bandwidth class. In the Source column, he creates a Combined Source 
Object, naming it for the CEO. He combines the Client IP/subnet object already created for 
each office with a User object that he creates for the CEO. 

The administrator places all three CEO rules above the employee rules, because the SG 
appliance looks for the first rule that matches a given situation and ignores the remaining 
rules. If he had placed the CEO rules below the employee rules, the SG appliance would 
never get to the CEO rules because the CEO's Web surfing client IP address matches both 
the CEO rules and the employee rules, and the SG appliance would stop looking after the 
first match. With the CEO rules placed first, the SG appliance applies the CEO rules to the 
CEO's Web surfing, and an employee's Web surfing does not trigger the CEO rules and 
instead skips ahead to the appropriate employee rule. 

Task Three: Bandwidth Allocation 

It soon becomes apparent that CEO visits are causing problems for the branch offices. At 
times, she uses all of the available bandwidth, resulting in decreased productivity 
throughout the office she visits. Also, management has complained that they have been 
given the same priority for FTP and HTTP traffic as regular employees, and they are 
requesting that they be given priority over employees for this type of traffic. 

First, the administrator creates two new classes for each office. In this example, we look at 
the classes and configurations for the first office only. He creates a class called Staff_A and 
sets a minimum bandwidth of 500 kbps on it. He also creates a class called Mgmt_A, 
setting the priority to 1 and the parent to Staff_A. He edits the class Emp_A, setting the 
parent to Staff_A. Finally, he edits the class CEO_A, changing the priority to 2. The 
resulting hierarchy is illustrated below. To see what the administrator did to the policy 
rules, see "Task Three: VPM" on page 83. 
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total of 500 kbps. The CEO's priority level has no effect until that minimum is satisfied. 
This means that the CEO can only use 250 kbps of bandwidth if the rest of the staff are 
using a total of 500 kbps. It also means that the CEO can use 750 kbps if no one else is 
using bandwidth at the time. In fact, any of the classes can use 750 kbps if the other classes 
use none. 

Priority levels kick in after all of the minimums are satisfied. In this example, if the staff 
requests more than 500 kbps, they can only receive it if the CEO is using less than 250 
kbps. Now notice that the minimum setting for the staff is set on the parent class, Staff_A, 
and not on the child classes, Emp_A or Mgmt_A. This means that the two child classes, 
representing employees and management, share a minimum of 500 kbps. But they share it 
based on their priority levels. This means that management has priority over employees. 
The employees are only guaranteed a minimum if management is using less than 500 
kbps. 

Task Three: VPM 

The administrator has added additional classes for each office and edited the existing 
employee classes, as described above in "Task Three: Bandwidth Allocation”. One of the 
new classes he added for each office is a parent class that does not have traffic classified to 
it; it was created to provide a minimum amount of bandwidth to its child classes. Not 
every class in the hierarchy has to have a traffic flow. This means that he needs to add just 
three more rules for the three new management classes. For the management rules, he 
selects the same combined FTP/HTTP object in the Service column; in the Action column, 
he selects a Manage Bandwidth object configured for client side/outbound with the 
bandwidth class one of the management classes (Mgmt_A, Mgmt_B, or Mgmt_C). In the 
Source column, he creates a Combined Source Object containing the subnet object for the 
office and the Group object for management. 

The management rules must go above the employee rules, although it does not matter 
where they are placed in relation to the CEO rules. This would not be true if the CEO was 
part of the same group as management, however. If that were true, the CEO rules would 
still need to go on top. 

Task Four: Bandwidth Allocation 

The administrator decided later that he needed to guarantee employees some bandwidth. 
He configures a minimum for the class Emp_A, as illustrated below. 
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He decides to leave the minimum on the parent class Staff_A and not to set a minimum for 
the class Mgmt_A. This is okay, because the minimum of the parent class is available to its 
children if the parent class does not use all of it, and the only way that the CEO can get 
more than 250 kbps is if the employees and management combined use less than 500. 

This last change does not require additional changes to policy; the administrator has 
added a minimum to a class that he has already classified for traffic using policy. 

In the above scenario, the class called Staff_A does not have traffic configured for it — it 
was created to guarantee bandwidth minimums for its child classes. However, if it were 
configured for traffic, it would have a practical minimum of 300 kbps. The practical 
minimum of a parent class is equal to its assigned minimum bandwidth minus the 
minimums of its children. In that case, if the parent class Staff_A used 300 kbps and the 
child class Emp_A used 200 kbps, the child class MgmtA would not receive any 
bandwidth unless the class CEO_A was using less than 250 kbps. Under those 
circumstances, the administrator probably also needs to create a minimum for 
management. 

Task Five: Bandwidth Allocation 

The CEO makes another request, this time for the main office, the one the administrator 
himself works from. This office uses the content filtering feature of the SG appliance to 
control the types of Web sites that employees are allowed to view. Although the office uses 
content filtering, access to sports sites is not restricted because the CEO is a big fan. 

The administrator creates a bandwidth management class called Sports with a maximum 
bandwidth of 500 kbps and launches VPM to create policy for this class as described 
below. 

Task Five: VPM 

To classify traffic for the Sports class, the administrator opens VPM, creates a Web Access 
Layer, and sets the Destination column to the Category object that includes sports viewing 
(content filtering is already set up in VPM). He sets the Action column to the Manage 
Bandwidth object, selecting Server side/inbound and the Sports bandwidth class he created. 
After installing the policy and verifying that bandwidth management is enabled, he is 
finished. 
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Policy Examples: CPL 

The examples below are complete in themselves. The administrator uses CLI to create and 
configure bandwidth management classes and writes CPL to classify traffic flow for these 
classes. These examples do not make use of a bandwidth class hierarchy. For examples of 
hierarchies, see "Bandwidth Allocation and VPM Examples" on page 78. 

Example One: CPL 

In this example, the administrator of a college is asked to prevent college students from 
downloading MP3 files during peak hours, while still allowing the music department to 
download MP3 files at any time. The CPL triggers used are authentication and/ or source 
subnet and MIME type. The action taken is to limit the total amount of bandwidth 
consumed by students to 40 kbps. 

CLI commands: 

SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create mp3 
SGOS# (config bandwidth-management) edit mp3 
SGOS# (config bw-class mp3) max-bandwidth 40 

CPL: 

define condition student_mp3_weekday 

client_address =student_subnet response^header . Content-Type="audio/ 
mpeg" \ 

weekday=l . . 5 hour=9 . . 16 
end condition 

<proxy> 

condition=student_mp3_weekday limit_bandwidth . server . inbound (mp3 ) 

Example Two: CPL 

In this example, an administrator must restrict the amount of bandwidth used by HTTP 
POST requests for file uploads from clients to 2 Mbps. The CPL trigger used is request 
method, and the action taken is to throttle (limit) the amount of bandwidth used by client 
side posts by limiting inbound client side flows. 

CLI: 

SGOS# (config) bandwidth-management 

bandwidth-management) create http_post 

SGOS# (config bandwidth-management) edit http_post 

SGOS# (config bw-class http_post) max-bandwidth 2000 

CPL: 

define condition http_posts 
http ,method=POST 
end condition 

<proxy> 

condition=http_posts limit_bandwidth . client . inbound (http_post) 

Example Three: CPL 

In this example, the administrator of a remote site wants to limit the amount of bandwidth 
used to pre-populate the content from headquarters to 50 kbps during work hours. The 
CPL triggers used are current-time and pre-population transactions. The action taken is to 
limit the total amount of bandwidth consumed by pre-pop flows. 

CLI: 
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SGOS# (config) bandwidth-management 

SGOS# (config bandwidth-management) create pre-pop 
SGOS# (config bandwidth-management) edit pre-pop 
SGOS# (config bw-class pre-pop) max-bandwidth 50 

CPL: 

define condition prepop_weekday 

content_management=yes weekday=l . . 5 hour=9..16 
end condition 

<proxy> 

condition=prepop_weekday limit_bandwidth . server . inbound (pre-pop) 
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This chapter discusses device authentication, which is a mechanism that allows devices 
to verify each others' identity; devices that are authenticated can be configured to trust 
only other authenticated devices. 



Note: SG appliance authentication is always used in association with other SGOS 

features. For example, you can use appliance authentication with the ADN 
implementation of secure tunnels. The secure tunnels feature uses authentication, 
the process of verifying a device's identity, with authorization, the process of 
verifying the permissions that a device has. For information on secure tunnels and 
appliance authentication, see Section D: "Securing the ADN Network" on page 32. 



Introduction 

Device authentication is important in several situations: 

□ Securing the network. Devices that are authenticated have exchanged certification 
information, verified each others' identity and know which devices are trusted. 

□ Securing protocols. Many protocols require authentication at each end of the 
connection before they are considered secure. 

This chapter discusses the following topics: 

□ "SG Appliance Overview" 

□ "Appliance Certificates and Device Authentication Profiles" on page 88 

□ "Creating an Authentication Profile" on page 93 

□ "Related CLI Syntax to Manage Device Authentication" on page 95 

□ "Obtaining a Non Blue Coat Appliance Certificate" on page 93 

□ "Related CLI Syntax to Manage Device Authentication" on page 95 

SG Appliance Overview 

The Blue Coat implementation allows devices to be authenticated without sending 

passwords over the network. Instead, a device is authenticated through certificates and 

profiles that reference the certificates. Both the profile and the referenced certificate are 

required for device authentication. 

□ Certificates: Certificates contain information about a specific device. Blue Coat runs 
an Internet-accessible Certificate Authority (CA) for the purpose of issuing 
appliance certificates to SGOS devices. You can also create your own appliance 
certificates. 

□ Profiles: A profile is a collection of information used for device-to-device 
authentication, including if the device has a certificate and if the certificates of other 
devices should be verified. The built-in profile is called bluecoat-appliance-certificate 
and references the appliance certificate on your SG appliance; you can create 
additional profiles. 
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Note: Authenticating the SG appliance and authenticating the SG appliance server 

name are two different procedures that require two different certificates. For 
information on authenticating server names, refer to Volume 4: Securing the Blue Coat 
SG Appliance. 



Appliance Certificates and Device Authentication Profiles 

In the Blue Coat implementation of device authentication, both an appliance certificate 
and a device authentication profile that references the appliance certificate keyring are 
required for device authentication to be successful. Each device to be authenticated must 
have an appliance certificate and a profile that references that certificate. 

Note that device authentication does not take effect unless the profile is enabled; for 
example, if you use WAN optimization, you enable the profile on the Configuration > App. 
Delivery Network > General > Device Security tab. 

About SG Appliance Certificates 

SG appliances come with a cryptographic key that allows the system to be authenticated 
as an SG appliance when an appliance certificate is obtained. 

An appliance certificate is an X.509 certificate that contains the hardware serial number of 
a specific SG device as the CommonName (CN) in the subject field. This certificate then 
can be used to authenticate the SG appliance whose hardware serial number is listed in 
the certificate. Information from the presented certificate is extracted and used as the 
device ID. 

Blue Coat runs an Internet-accessible CA for the purpose of issuing appliance certificates. 
The root certificate for the Blue Coat CA is automatically trusted by SGOS for device 
authentication. These Blue Coat-signed certificates contain no authorization information 
and are valid for five years. 

You can provide your own device authentication certificates for the SG appliances on your 
network if you prefer not to use the Blue Coat CA. 

About Device Authentication Profiles 

A device authentication profile contains the information related to device authentication: 

□ The name of the keyring that contains the private key and certificate this device uses to 
authenticate itself. The default is appliance-key. (For information on private and 
public keys, refer to Volume 4: Securing the Blue Coat SG Appliance.) 

□ The name of the CA Certificate List (CCL) that contains the names of certificates of 
CAs trusted by this profile. If another device offers a valid certificate signed by an 
authority in this list, the certificate is accepted. The default is appliance-ccl. 

□ Verification of the peer certificate. 

When the SG appliance is participating in device authentication as an SSL client, the 
peer certificate verification option controls whether the server certificate is validated 
against the CCL. If verification is disabled, the CCL is ignored. 

When the SG appliance is participating in device authentication as an SSL server, the 
peer certificate verification option controls whether to require a client certificate. If 
verification is disabled, no client certificate is obtained during the SSL handshake. The 
default is verify-peer-certificate enabled. 
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□ Specification of how the device ID authorization data is extracted from the certificate. 
The default is $( subject. CN) . 

□ SSL cipher settings. The default is AES256-SHA. 

Each Blue Coat appliance has an automatically-constructed profile called bluecoat- 
appliance-certificate that can be used for device-to-device authentication. This profile 
cannot be deleted or edited. 

If you cannot use the built-in profile because, for example, you require a different cipher 
suite or you are using your own appliance certificates, you must create a different profile, 
and have that profile reference the keyring that contains your certificate. 



Note: If you do not want to use peer verification, you can use the built-in passive- 

attack-detection-only profile in place of the bluecoat-appliance-certificate profile. 

This profile uses a self-signed certificate and disables the verify-peer option, so that 
no authentication is done on the endpoints of the connection. The traffic is encrypted, 
but is vulnerable to active attacks. 

This profile can be used only when there is no threat of an active man-in-the-middle 
attack. Like the bluecoat-appliance certificate profile, the passive-attack-detection-only 

profile cannot be edited or deleted. 



If you create your own profile, it must contain the same kind of information that is 
contained in the Blue Coat profile. To create your own profile, skip to "Creating an 
Authentication Profile" on page 93. 

Obtaining an SG Appliance Certificate 

In many cases, if you have Internet connectivity, an appliance certificate is automatically 
fetched by the SG appliance, and no human intervention is required. In other cases, if the 
Internet connection is delayed or if you do not have Internet access, you might have to 
manually initiate the process of obtaining an appliance certificate. 

How you obtain an appliance certificate depends upon your environment: 

□ If the device to be authenticated has Internet connectivity and can reach the Blue Coat 
CA server, continue with "Automatically Obtaining an Appliance Certificate" on page 
90. 

□ If the device to be authenticated cannot reach the Blue Coat CA server, you must 
acquire the certificate manually; continue with "Manually Obtaining an Appliance 
Certificate" on page 90. 

After the certificate is obtained, you must configure the device to use the profile you 
choose to use. For information on configuring the device to use the profile, see Chapter 2: 
"Configuring an Application Delivery Network". 

If you are configuring device authorization as well as authentication, configure device 
authentication before authorization. For more information on device authorization, see 
Chapter 2: "Configuring an Application Delivery Network". 
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Important: Only the following SG platforms support appliance certificates: 

□ SG200 (manufactured after August 1, 2006) 

□ SG210 

□ SG510 

□ SG810 

□ SG8100 

If you attempt to obtain an appliance certificate for other platforms (through 

Configuration > SSL > Appliance Certificates > Request appliance certificate), the request 
fails with the following error message: 

□ Request failed: Signing server reported error: No such serial number serial number. 

If you receive this message, you cannot use Blue Coat appliance certificates, but you can 
create your own appliance certificates for use in a secure network. For more 
information, see "Obtaining a Non Blue Coat Appliance Certificate" on page 93. 



Automatically Obtaining an Appliance Certificate 

The appliance attempts to get the certificate completely automatically (with no user 
intervention) if it can connect to the Blue Coat CA server at boot time or within about five 
minutes of being booted. If the appliance does not have a certificate (for example, it had 
one until you did a restore-defaults factory-defaults command) it attempts to get 
one on every boot. Once the appliance gets a certificate, that certificate is used until 
another restore-defaults factory-defaults command is issued. 

If Internet connectivity is established more than five minutes after the system is booted, 
you might need to complete the following steps. 

To automatically obtain an appliance certificate: 

1. Select Configuration > SSL > Appliance Certificates > Request Certificate. 

2. Click Request appliance certificate. 

The Blue Coat CA server does validation checks and signs the certificate. The 
certificate is automatically placed in the appliance-key keyring. Note that the 
appliance-key keyring cannot be backed up. The keyring is re-created if it is missing 
at boot time. 

Manually Obtaining an Appliance Certificate 

Complete the following steps to obtain an appliance certificate manually. The overview of 
the procedure is to: 

□ Generate a appliance certificate signing request and send it to the Blue Coat CA server 
for verification and signature. 

□ Import the signed certificate into the SG appliance. 

To generate a CSR: 

1. Select Configuration > SSL > Appliance Certificates > Request Certificate. 

2. Select Create CSR. 



90 



Chapter 6: Authenticating an SG Appliance 




3. Copy the certificate request, including the certificate request signature. Be sure to 
include the "Begin Certificate" and "End Certificate" statements, as well as the "Begin 
CSR Signature" and "End CSR Signature" statements. 

4. Click OK. 

5. Go to the Blue Coat CA Server Website at https:/ / abrca.bluecoat.com/ sign-manual/ 
index.html. 



Blue Coat - ABRCA Manual Form 



|| BEGIN CERTIFICATE REQUEST 

M 1 1 B x z CC AT AC AQ AwgY Yx C z A J B gNVB AYTA 1 VTMQs wC Q YD VQQ I E w J D QTE SMB AGA 1 UE 
B x H J U3 Vub nl2 YTJx IMS AwHgYDVQQKExdCbHVl IENvYXQgU3 1 z dGVt c y wgS W5 j Lj E f 
HBOGAlUECxMWQmxlZSBDb2FOIFNHMjAwIFNlcmllczETMBEGAlUEAxMKNDUwNTA2 
HD Ay MD C B n z ANB gkqhk i G9 wO B AQE F A AOB j QAwg YkC g YE At 1 Y3 S a 1 1 s 6 AD Y8 B P YhVb 
MrvA/ aRs0Ed60CwwsuxiFSTHn3 i jDug5ttT5DDvfmxy4YcgP7vdTaeVdqeQDBwkM 
FpjxxUfj THX INge B WKhTM8 UL c 0/ gB a8 z 7 c IJUr y x y GS 9FS3H2ZBZXSx SvQT 1 9 z Uu3 
2 X A3 Qt 1 1 r 8 RH7 MM 1 dto P omr 0 C A wE A Aa A AM AO GC S qGS lb 3 D QE B B AUAA4 GB AHB i kVOc 
Tj M8 zDmPtt I I7dMNCwmf P Iy3 zeyppdr MFL 1 JcnJ j wqhlXr ndN7WHYUXEwhYJtU9p 
70kyFs+giBt I zdd8f nZaeF4 JXNC zSf Lq¥npKOj TBA9¥LTMc IThIHp 1UZE/ T1 1DRS 
kZ6AfyhJQGhxmKuAi8LLRjPMO5Y0owxo8A17 

END CERTIFICATE REQUEST 

BEGIN CSR SIGNATURE 

CSR+Signature Ks j- q F GaS -j 2 Az+GL/Hm90FnanBzLg0svA¥BbaYD6‘JqNr(i3VH17ADaHw2Lfr ZlD13ez 
B0gxKJEBU5w7TULG23 QJV3 Xp wP 7 XOb 6rns 1 e kg/ XPN Z 2 OrtioN j 13 Vr e J +A9 us Yp Uhh 
S6qFKf IcivnDchukchI= 

END CSR SIGNATURE 



[ Generate Cert j 

6. Paste the CSR and signature into the CSR panel. 
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7. Click Generate Cert. 

The signed certificate displays, and can be pasted into the appliance-key keyring. 

BEGIN CERTIFICATE 

MI IF/ jCCBOagAwIBAgICAMowDQYJKoZIhvcNAQEFBQAwgbYxCzAJBgNVBAYTAlVT 
MRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTdW5ueXZhbGUxIDAeBgNV 
BAoTFO JsdWUgQ2 9hdCBTeXN0ZWlzLCB JbmMuMRkwFwYDVQQLExBCbHVlIENvYXQs 
IEFCUkNBMRswGQYDVQQDEx JhYn Jj YS5ibHVlY2 9hdC5 jb2 Ox JDAiBgkqhkiG9wOB 
CQEWFXN5c2FkbWluQGJsdWVjb2F0LmNvbTAeFw0wNzAxMj kyMDM5NDdaFw0xMj Ax 
Mj kyMDM5NDdaMIGGMQswCQYDVQQGEwJVUzELMAkGAlUECBMCQ0ExE j AQBgNVBAcT 
CVNlbm55dmFsZTEgMB4GAlUEChMXQmxlZSBDb2F0IFN5c3RlbXMsIEluYy4xHzAd 
BgNVBAsTFkJsdWUgQ2 9hdCBTRzIwMCBTZXJpZXMxEzARBgNVBAMTC j AlMDUwNj Aw 
OTIwgZ8wDQY JKoZIhvcNAQEBBQADgYOAMIG JAoGBAMBUmCuKSsSd+D5kJQiWu30G 
DNLCvf 7SyKK5+SBC JU2iKwP5+Ef iQ5 JsScWJghtIo94EhdSC2zvBPQqWbZAJXN7 4 
k/ yM4w9uf j f o+G7xPYcMrGmwVBGnXbEhQkagclFH2or INNY8SVDYVLlV4dRM+0at 
YpEiBmSxipmRSMZL4kqtAgMBAAGj ggLGMIICw j AJBgNVHRMEAj AAMAsGAlUdDwQE 
AwIE8DBOBgNVHSUERzBFBggrBgEFBQcDAQYIKwYBBQUHAwIGCCsGAQUFBwMEBgsr 
BgEEAfElAQECAQYLKwYBBAHx JQEBAgIGCysGAQQB8SUBAQIDMB0GAlUdDgQWBBSF 
NqC2ubTI70T5 j +KqCPGlSDO7DzCB6wYDVR0 jBIH jMIHggBSwEYwcqlN6Gl ZhpcXn 
OTIu8 fNelaGBvKSBuTCBt j ELMAkGAlUEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3 Ju 
aWExE j AQBgNVBAcTCVNlbm55dmFsZTEgMB4GAlUEChMXQmxl ZSBDb2F0 IFN5c3Rl 
bXMsIEluYy4xGTAXBgNVBAsTEE JsdWUgQ2 9hdCwgQUJSQ0ExGzAZBgNVBAMTEmFi 
cmNhLmJsdWVjb2F0LmNvbTEkMCIGCSqGSIb3DQEJARYVc31zYWRtaW5AYmxlZWNv 
YXQuY2 9tggkAhmhbUPEEb60wgZ8GCCsGAQUFBwEBBIGSMIGPMEkGCCsGAQUFBzAB 
hj lodHRwczovL2FicmNhLmJsdWVjb2F0LmNvbS9 j Z2ktYmluL2Rldml j ZSlhdXRo 
ZW50aWNhdGlvbi 9vY3NwMEIGCCsGAQUFBzACh j ZodHRwOi8vYWJyY2EuYmxl ZWNv 
YXQuY2 9tL2Rldml j ZSlhdXRoZW50aWNhdGlvbi9 j YS5 j Z2kwSAYDVR0fBEEwPzA9 
oDugOYY3aHROcDovL2FicmNhLmJsdWVjb2FOLmNvbS9kZXZpY2UtYXVOaGVudGlj 
YXRpb 2 4 vQ 1 JMLmNybDBf BgNVHS AEWDBWMFQGC i s GAQQB8 SUBAQEwR j BEBggr BgE F 
BQcCARY4aHR0cDovL2FicmNhLmJsdWVjb2F0LmNvbS9kZXZpY2UtYXV0aGVudGlj 
YXRpb24vcnBhLmh0bWwwDQYJKoZIhvcNAQEFBQADggEBACIhQ7Vu6aGJBpxP255X 
d2/ Qw7NiVsnq01Ay913QZlieFfVAT JnCeSrH+M9B/2XtnRxVT0/ZWr f 4GbsdYqTF 
he 9 jR/IwKu6kZq32Dqo8qFU50zbAEzT2oebB5QgwuJtHcJHggp9PS9uS27qAnGQK 
OeB2bYc j WtMvTvr50iDOV6 9BEQz+VXos8QiZmRHLVnebQS j 13bilw3Vj Bw31tCmc 
clgz0SlN9ZmJdRU/PlWdNVqD4OLqcMZQ53HqcdWNEzN2uvigIb//rM7XazK7xIaq 
r23/ +BsZlYKAeVMq3PEmxaA2 zLzO+ j f 7 9a8 ZvIKrF27nNuTN7NhFL/V6pWNElo9A 
rbs = 

END CERTIFICATE 

import a certificate onto the SG appliance: 

Copy the certificate to your clipboard. Be sure to include the "Begin Certificate" and 
"End Certificate" statements. 

Select Configuration > SSL > Keyrings. 

Select the keyring that is used for device authentication. The keyring used by the 
bluecoat-appliance-certificate profile is the appliance-key keyring. 

Click Edit/View in the Keyrings tab. 



To 

1 . 

2 . 

3. 

4. 
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5. In the Certificate panel, click Import. 

6. Paste the certificate you copied into the dialog box. Click OK. 

The certificate should display in the SSL Certificates Pane, associated with the keyring 
you selected earlier. 

Obtaining a Non Blue Coat Appliance Certificate 

If you run your own certificate signing authority for device authentication, complete the 
following steps: 

1. Create a keyring for the appliance's certificate. For information on creating a keyring, 
refer to Volume 4: Securing the Blue Coat SG Appliance. 

2. Generate the certificate signing request and get it signed. For information on creating 
a CSR, refer to Volume 4: Securing the Blue Coat SG Appliance. 



Note: You cannot put a Blue Coat appliance certificate into a keyring you create 

yourself. 



3. Create a CA certificate list.For information on creating a CCL, refer to Volume 4: 
Securing the Blue Coat SG Appliance 

a. Import the CA's root certificate. 

b. Add the certificate to the CCL. 

4. Create a device authentication profile. (To create a profile, see "Appliance Certificates 
and Device Authentication Profiles" on page 88.) 

5. Associate the profile with the keyring and CCL. The keyring and CCL must already 
exist. 

Adjust other parameters, including authorization data extractor (if the certificate is to 
be used for authorization), as needed. 

Configure each application that uses device authentication to reference the newly created 
profile, and set up its whitelist. To associate the device with the profile, see Chapter 2: 
"Configuring an Application Delivery Network". 

Creating an Authentication Profile 

Am authentication profile only needs to be created if you cannot use the built-in bluecoat- 

appliance-certificate profile without modification; note that the bluecoat-appliance- 

certificate profile cannot be deleted or edited. 

Additional profiles with different settings can be created; for example, if you require a 
different cipher setting than what the bluecoat-appliance-certificate profile uses, you can 
create a profile with the different cipher suite. 

To create a new authentication profile: 

1. Select Configuration > SSL > Device Authentication > Profiles. 

2. Click New. 
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3. Name: Give the profile a meaningful name. The only valid characters are 
alphanumeric, the underscore, and hyphen, and the first character must be a letter. 

4. Keyring: From the drop-down list, select the keyring you want to use for device 
authentication. 



Note: You must create a new keyring for device authentication if you do not use the 
appliance-key keyring. The keyrings shipped with the Blue Coat SG are dedicated to 
other purposes. For information on creating a new keyring, refer to Volume 4: Securing 
the Blue Coat SG Appliance. 



5. CCL: From the drop-down list, select the CA Certificate List you want to use. 

6. Device ID extractor: The field describes how device ID information is extracted from a 
presented certificate. The string contains references to the attributes of the subject or 
issuer in the form $ (subject . at tr[ . n] ) or $ (issuer .attr [ . n] ) , where attr is the 
short-form name of the attribute and n is the ordinal instance of that attribute, 
counting from 1 when the subject is in LDAP (RFC 2253) order. If n is omitted, it is 
assumed to be 1. 

The default is $ ( subj ect . CN) ; many other subject attributes are recognized, among 
them OU, O, L, ST, C, and DC. 

7. Verify peer: This setting determines whether peer certificates are verified against the 
CCL or whether client certificates are required. 

8. Selected cipher suites: If you want to use a different cipher suite, click Edit cipher 
suites. 
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9. Select the cipher suite or suites you want to use. Click Add to add the cipher suite to 
the list of selected cipher suites. Cipher suites that you do not want to use should be 
removed from the selected list. 

10. Click OK when done. 

11. Click Apply to commit the changes to the SG appliance. 



Related CLI Syntax to Manage Device Authentication 

□ To enter configuration mode: 

SGOS# (config) ssl 

□ The following device-authentication commands are available: 

SGOS# (config ssl) create device-authentication-profile profile_name 
keyring_ID 

SGOS# (config ssl) edit device-authentication-profile test 
SGOS# (config device-auth test) cipher-suite cipher-suite 
SGOS# (config device-auth test) ccl ccl^name 
SGOS# (config device-auth test) device-id device^ID 
SGOS# (config device-auth test) exit 

SGOS# (config device-auth test) keyring-id keyring_ID 
SGOS# (config device-auth test) verify-peer [enable | disable] 
SGOS# (config device-auth test) view 
SGOS# (config ssl) request-appliance-certificate 
SGOS# (config ssl) view appliance-certificate-request 
SGOS# (config ssl) view device-authentication-profile 
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Using IP address failover, you can create a redundant network for any explicit proxy 
configuration. If you require transparent proxy configuration, you can create software 
bridges to use failover. For information on creating software bridges, refer to Volume 1: 
Getting Started. 



Note: If you use the Pass-Through adapter for transparent proxy, you must create a 
software bridge rather than configuring failover. For information on using the Pass- 
Through adapter, refer to Volume 1: Getting Started. 



Using a pool of IP addresses to provide redundancy and load balancing. Blue Coat 
migrates these IP addresses among a group of machines. 

This chapter discusses: 

a "About Failover" 

□ "Configuring Failover" on page 98 

About Failover 

Failover allows a second machine to take over if a first machine fails, providing 
redundancy to the network through a master /slave relationship. In normal operations, 
the master (the machine whose IP address matches the group name) owns the address. 
The master sends keepalive messages ( advertisements ) to the slaves. If the slaves do not 
receive advertisements at the specified interval, the slave with the highest configured 
priority takes over for the master. When the master comes back online, the master takes 
over from the slave again. 

The Blue Coat failover implementation resembles the Virtual Router Redundancy 
Protocol (VRRP) with the following exceptions: 

□ A configurable IP multicast address is the destination of the advertisements. 

□ The advertisement interval is included in protocol messages and is learned by the 
slaves. 

□ A virtual router identifier (VRID) is not used. 

□ Virtual MAC addresses are not used. 

□ MD5 is used for authentication at the application level. 

Masters are elected, based on the following factors: 

□ If the failover mechanism is configured for a physical IP address, the machine 
owning the physical address have the highest priority. This is not configurable. 

□ If a machine is configured as a master using a virtual IP address, the master has a 
priority that is higher than the slaves. 

When a slave takes over because the master fails, an event is logged in the event log. 
No e-mail notification is sent. 
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Configuring Failover 

Before you begin, ensure that software bridges already exist. For information on 
configuring bridges, refer to Volume 1: Getting Started. 

You also must decide which machine is the master and which machines are the slaves, and 
whether you want to configure explicit proxy or transparent proxy network. 

When configuring the group, the master and all the systems in the group must have 
exactly the same failover configuration except for priority, which is used to determine the 
rank of the slave machines. If no priority is set, a default priority of 100 is used. If two 
appliances have equal priority, the one with the highest physical address ranks higher. 



Note: Configuring failover on an Application Data Network (ADN) is similar to 

configuring failover on other appliances, with the exception that you add a server 
subnet on multiple boxes instead of just one. 



To configure failover: 

1. Select Configuration > Network > Advanced > Failover. 

2. Click New. 




3. Fill in the fields as appropriate: 

a. Create a group using either a new IP address or an existing IP address. If the 
group has already been created, you cannot change the new IP address 
without deleting the group and starting over. 

b. Multicast address refers to a Class D IP address that is used for multicast. It is 
not a virtual IP address. 
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Note: Class D IP addresses (224 to 239) are reserved for multicast. A Class D IP 
address has a first bit value of 1, second bit value of 1, third bit value of 1, and 
fourth bit value of 0. The other 28 bits identify the group of computers that 
receive the multicast message. 



c. Relative Priority refers to a range from 1-255 that is assigned to systems in the 
group. 255 is reserved for the system whose failover group ID equals the real 
IP address. (Optional) Master identifies the system with the highest priority 
(the priority value is greyed out). 

d. (Optional) Advertisement Interval refers to the length of time between 
advertisements sent by the group master. The default is 40 seconds. If the 
group master fails, the slave with the highest priority takes over (after 
approximately three times the interval value). The failover time of the group 
is controlled by setting this value. 

e. (Optional, but recommended) Group Secret refers to a password shared only 
with the group. 

f. Select enabled. 

g. Click OK. 

4. Click Apply to commit the changes to the SG appliance. 



Related CLI Syntax to Configure Failover 

□ To enter configuration mode: 

SGOS# (config) failover 



□ The following subcommands are available: 

SGOS# (config failover) create groupaddress 



SGOS# (config failover) 
SGOS# (config failover 
multicast_address 
SGOS# (config failover 
SGOS# (config failover 
SGOS# (config failover 
SGOS# (config failover 
-or- 

SGOS# (config failover 
SGOS# (config failover 



edit groupaddress 
group_address) multicast-address 



group_address) 

group_address) 

group_address) 

group_address) 



master 

priority number 
interval seconds 
secret secret 



group_address) encrypted-secret encrypted_secret 
group^address) enable 



Viewing Failover Statistics 

At any time, you can view statistics for any failover group you have configured on your 
system. 

To view failover status: 

1. Select Statistics > System > Failover. 
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Status 



Failover Group: 10.9.16.150 



V 



Failover status: 



Multicast address: 
Local address: 
State: 

Flags: 



224.1.2.3 
10.9.16.150 
MASTER 
R (Real IP) 



2. From the drop-down list, select the group to view. 

The information displayed includes the multicast address, the local address, the state, and 
any flags, where V indicates the group name is a virtual IP address, R indicates the group 
name is a physical IP address, and M indicates this machine can be configured to be the 
master if it is available. 
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To fill requests, the SG appliance must interact with both the local network and with 
the upstream network environment. 

This chapter includes the following sections: 

□ Section A: "Overview" on page 102 

□ Section B: "About Forwarding” on page 103 

□ Section C: "Configuring Forwarding" on page 106 

□ Section D: "Using Forwarding Directives to Create an Installable List” on page 114 
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Section A: Overview 

To control upstream interaction, the SG appliance supports: 

□ The SG appliance forwarding system — Allows you to define the hosts and groups of 
hosts to which client requests can be redirected. Those hosts can be servers or proxies. 
Rules to redirect requests are set up in policy. 

□ SOCKS gateways — SOCKS servers provide application-level firewall protection for an 
enterprise. The SOCKS protocol provides a generic way to proxy HTTP and other 
protocols. For information on configuring SOCKS gateways, see Chapter 13: "SOCKS 
Gateway Configuration" on page 183. 

□ ICP — ICP handles ICP queries from other caching devices looking for cached data. The 
SG appliance also can use ICP. For information on configuring ICP, see Chapter 9: 
"Internet Caching Protocol (ICP) Configuration" on page 121. 
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Section B: About Forwarding 

Foriuarding allows you to redirect requests to IP addresses other than those specified in the 
URL. Forwarding also allows you to organize how the Web traffic flows around the 
network. Forwarding does not affect the URL that appears in the request. It only affects 
the IP address of the upstream device a request is sent to. 

The SG appliance forwarding system consists of forwarding, upstream SOCKS gateways, 
load balancing, host affinity, health checks, and ICP. The SG appliance forwarding system 
determines the upstream address where a request is sent, and is tied in with all the 
protocol agents, including HTTP, HTTPS, streaming, and FTP, and the network 
configuration. The combination of forwarding and the policy engine allows traffic 
management and flexible configuration. 



Note: The SG appliance forwarding system directly supports the forwarding of HTTP, 
HTTPS, FTP, Windows Media, RTSP, Telnet, and TCP tunnels. 



About Load Balancing 

Load balancing is a way to share traffic requests among multiple upstream systems or 
multiple IP addresses on a single host. Load-balancing methods include round robin, 
which selects the next system in the list, or least connections, which selects the system 
with the least number of connections among the selected group. 

You can configure load balancing two ways: 

□ For individual hosts: If a host is DNS-resolved to multiple IP addresses, then that 
host's load-balancing method (round robin, least connections, or none) is applied to 
those IP addresses. The method is either explicitly set for that host or taken from the 
configurable global default settings. 

□ For groups: Load balancing for groups works exactly the same as load balancing for 
hosts with multiple IP addresses — the forwarding system collects all of the IP 
addresses for all of the hosts in the group and load balances over that set using the 
method that is specified. You can also use a domain or URL hash, as well. 

About Host Affinity 

Host affinity is the attempt to direct multiple connections by a single user to the same 
group member. Host affinity is closely tied to load balancing behavior; both should be 
configured if load balancing is important. For example, a Web site uses shopping carts to 
allow customers to purchase items. The site might use load balancing with a group of Web 
servers working in parallel, but only one server in the group has information on a single 
user. If the user connections are sent to a different server, the server has no previous 
information on the user and might start over. 

Host affinity forces the user's connections to return to the same server until the user is 
idle. After a configurable period of inactivity, the host affinity times out and the 
association of multiple connections with that single user is lost. 

Host affinity allows you to use the following options: 

□ Use the client IP address to determine which group member was last used. When the 
same client IP sends another request, the host makes the connection is made to that 
group member. 
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□ Place a cookie in the response to the client. When the client makes further requests, the 
cookie data is used to determine which group member the client last used. The host 
makes the connection to that group member. 

□ For HTTPS, extract the SSL session ID name from the connection information. The host 
uses the session ID in place of a cookie or client IP address to determine which group 
member was last used. The host makes the connection to that group member. 

Using Load Balancing with Host Affinity 

By default, if you use load balancing, each connection is treated independently. The 
connection is made to whichever member of the load-balancing group that the load- 
balancing algorithm selects. The load balancing responsibility is to distribute the 
connections among group members to share the load. 

If host affinity is configured, the system checks host affinity first to see if the request 
comes from a known client. If this is a first connection, the load-balancing algorithm 
selects the group member to make the connection. Host affinity records the result of the 
load balancing and uses it if that client connects again. 

Host affinity does not make a connection to a host that health checks report is down; 
instead, if host affinity breaks, the load-balancing algorithm selects a group member that 
is healthy and re-establishes affinity on that working group member. 



Note: You might find it necessary to disable caching for traffic sent to the load-balanced 
groups (or hosts if DNS hides a group under one entry) to prevent copies of customized 
Web pages being served to a different user. 

It is not always necessary to disable caching; for example, load balancing can be used 
without host affinity or without disabling caching to distribute load among several 
proxies. 

However, if caching is enabled for traffic going through load balancing, retrieval of 
updated content by the cache is done according to load balancing rules; the cache does not 
support host affinity and ignores it if enabled. 



Host affinity methods are discussed in the table below. 
Table 8-1 . Host Affinity Methods 



Setting 


Description 


HTTP 


SSL 


Other (TCP 
Tunnel or 
Telnet) 


Global Default 


Use the default setting for all 
forwarding hosts on the system. 


✓ 


✓ 


✓ 


None 


Disables host affinity. 


✓ 




✓ 


Client IP Address 


Uses the client IP address to 
determine which group member 
was last used. 


✓ 


✓ 


✓ 


Accelerator 

Cookie 


Inserts a cookie into the response to 
the client. 


✓ 


✓ 
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Table 8-1 . Host Affinity Methods (Continued) 



SSL Session ID 


Used in place of a cookie or client IP 
address. Extracts the SSL session ID 




✓ 






name from the connection 
information. 
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Section C: Configuring Forwarding 

High-level steps to configure forwarding are: 

□ Create the forwarding hosts and groups, including parameters such as protocol agent 
and port. 

□ Set Load Balancing and Host Affinity values. 

Creating Forwarding Hosts and Groups 

You can create as many hosts, groups, or members of a group as you need. 

To create groups, see "To create forwarding groups:" on page 107 

To create forwarding hosts: 

1. Click Configuration > Forwarding > Forwarding Hosts. 

2. Click New to create a new forwarding host. 




3. Enter the fields as follows: 

a. In the Alias field, enter the name of the host as it will be named in policy. 
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Note: The host alias cannot be a CPL keyword, such as no, default, or 

forward. 



b. In the Host field, give the name of the host domain or its IP address. 

c. Define the host type by selecting either the Proxy or Server radio button. 
Terminated HTTPS, TCP tunnels, and Telnet can be forwarded to a server 
only; they cannot be forwarded to a proxy. Server specifies to use the relative 
path for URLs in the HTTP header because the next hop is a Web server, not a 
proxy server. The default is Proxy. 

d. Select the port you want to use. 

Port 80 is the default for HTTP. The rest of the host types default to their 
appropriate Internet default port, except TCP tunnels, which have no default and 
for which a port must be specified. 

e. In the Load Balancing and Host Affinity section, select a load-balancing 
method from the drop-down list. Global default (configured on the 
Configuration > Forwarding > Global Defaults tab), sets the default for all 
forwarding hosts on the system. You can also specify the load-balancing 
method for this system: Least Connections or Round Robin, or you can disable 
load balancing by selecting None. 

f. In the Host affinity methods drop-down list (see Table 8-1, "Host Affinity 
Methods," on page 104), select the method you want to use. 

4. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 

To create forwarding groups: 

An existing host can belong to one or more groups as needed. It can only belong once to a 

single group. 

1. Click Configuration > Forwarding > Forwarding Groups. 

2. Click New to create a new forwarding group. The Add Forwarding Group dialog 

displays, showing the available aliases. 
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Forwarding Hosts Forwarding Groups Global Defaults | Default Sequence j Install Forwarding File 




3. Enter a name for the new group in the Alias field. 



Note: The group alias cannot be a CPL keyword, such as no, default, or 

forward. 



4. To add members to a group, highlight the hosts you want grouped and click Add. You 
can also create a group with no members. 

5. In the Load Balancing and Host Affinity section, select the load-balancing method from 
the drop-down list. Global default (configured on the Configuration > Forwarding > 
Global Defaults tab), are the defaults that were set for all forwarding groups on the 
system. To specify the load-balancing method for this system, select Least 
Connections, Round Robin, Domain Hash, URL Hash, or you can disable load balancing 
by selecting None. 

6. In the Host affinity methods drop-down list (see Table 8-1, "Host Affinity Methods," 
on page 104), select the method you want to use. 

7. Click OK. 

8. Click Apply to commit the changes to the SG appliance. 
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Configuring Global Forwarding Defaults 

The global defaults apply to all forwarding hosts and groups unless the settings are 
specifically overwritten during host or group configuration. 

To configure global defaults: 

1. Select Configuration > Forwarding > Global Defaults. 

Forwarding Hosts Forwarding Groups Global Defaults 

r General Settings 

If no forwarding host is available: 

0 Connect directly (fail open) 

0 Deny the request (fail closed) 

0 Use forwarding for administrative downloads 
Timeout for integrated hosts: 60 minutes 



- Load Balancing and Host Affinity 

Load balancing methods: 




Host affinity timeout: ^30 minutes 

2. Configure General Settings as follows: 

a. Determine how you want connections to behave if no forwarding is available. 
Note that failing open is an insecure option. The default is to fail closed. This 
setting can be overridden by policy, if it exists. 

b. Decide if you want to Use forwarding for administrative downloads. The 

default is to use forwarding in this case. 

This option determines whether forwarding is applied to requests generated for 
administrative reasons on the system, such as downloading policy files or new 
system images. 

If the option is on, meaning that forwarding is applied, you can control the 
forwarding in policy as needed. 

This option also affects the use of SOCKS gateways. 

c. Enter the Timeout for integrated hosts interval: An integrated host is an Origin 
Content Server (OCS) that has been added to the health check list. The host, 
added through the integrate new hosts policy property, ages out after 
being idle for the specified time. The default is 60 minutes. 

3. Configure Global Load Balancing and Host Affinity Settings. 
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a. Load-balancing methods: 

• Forwarding hosts: Specify the load-balancing method for all forwarding hosts 
unless their configuration specifically overwrites the global settings. You can 
choose Least Connections or Round Robin, or you can disable load balancing 
by selecting None. Round Robin is specified by default. 

• Forwarding groups: Specify the load-balancing method for all forwarding 
groups unless their configuration specifically overwrites the global settings. 
You can choose to do a domain hash or a URL hash. You can also select Least 
Connections or Round Robin, or disable load balancing by selecting None. 
Round Robin is specified by default. 

b. In the Global Flost Affinity methods (see Table 8-1, "Flost Affinity Methods," 
on page 104), select the method you want to use. 

c. Enter the Host Affinity Timeout interval, the amount of time a user's IP 
address, SSL ID, or cookie remains valid after its most recent use. The default 
is 30 minutes, meaning that the IP address, SSL ID or cookie must be used 
once every 30 minutes to restart the timeout period. 

4. Click Apply to commit the changes to the SG appliance. 

Configuring the Default Sequence 

The default sequence is the default forwarding rule, used for all requests lacking policy 
instructions. Failover is supported if the sequence (only one is allowed) has more than one 
member. 



Note: Creating the default sequence through the CLI is a legacy feature. You can set up 
sequences by using policy alone. The default sequence (if present) is applied only if no 
applicable forwarding gesture is in policy. 

For information on using VPM, refer to Volume 6: VPM and Advanced Policy ; for 
information on using CPL, refer to Volume 10: Content Policy Language Guide. For 
information on using forwarding with policy, see Appendix B: "Using Policy to Manage 
Forwarding" on page 263. 



The default sequence (and any sequence specified in policy) works by allowing healthy 
hosts to take over for an unhealthy host (one that is failing its DNS Resolution or its health 
check). If more than one member is in the sequence, the sequence specifies the order of 
failover, with the second host taking over for the first host, the third taking over for the 
second, and so on. 



Note: In normal circumstances, only the first member of the sequence is ever used. Traffic 
is forwarded to the first member of the sequence until it fails, then traffic is sent to the 
second member of list until it fails or the first member becomes healthy again, and so on. 
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To create a default sequence: 

1. Select Configuration > Forwarding > Default Sequence. The available aliases are 
displayed. 

Forwarding Hosts | Forwarding Groups ' Global Defaults Default Sequence | Install Forwarding File 

- Default Fail-Over Sequence 

Available Aliases Selected Aliases 

Alias name 



testl 



2. To select an alias, highlight it and click Add. 



Note: Any host or group in the default sequence is considered in use by policy. As a 

result, if you try to delete a host or group while it is in the default sequence, you 
receive an error message. You must remove the host / group from the sequence first, 
then delete the host or group. 



3. Click Promote or Demote to change the order of the hosts in the failover sequence. 

4. Click Apply to commit the changes to the SG appliance. 

Related CLI Syntax to Configure Forwarding 

□ To enter configuration mode for forwarding: 

SGOS# (config) forwarding 
SGOS# (config forwarding) 

□ The following subcommands are available: 

SGOS# (config) forwarding 

SGOS# (config forwarding) create host host^alias host_name [http [=port] 
[https [=port] ] [ftp[=port]] [ mms [=port] ] [rtsp [=port] ] [tcp [=port] ] 
[telnet [=port] ] [ssl-verify-server [=yes | =no] ] [qroup=group_name] 
[server | proxy] 

SGOS# (config forwarding) create group group_name 

SGOS# (config forwarding) delete all 

SGOS# (config forwarding) delete group group_name 

SGOS# (config forwarding) delete host host_alias 

SGOS# (config forwarding) download-via-f orwarding {disable | enable} 





Alias name 


Add » 




Promote 




Demote 




« Remove 1 
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SGOS# (config forwarding) edit host^alias 

SGOS# (config forwarding hostalias) exit 

SGOS# (config forwarding host_alias) {ftp | http | https | mms | 
rtsp | tcp | telnet} [port] } 

SGOS# (config forwarding host_alias) host hostname 

SGOS# (config forwarding host_alias) host-affinity http {default | 
none | client- ip-address | accelerator-cookie} 

SGOS# (config forwarding host_alias) host-affinity ssl {default | 
none | client- ip-address | accelerator-cookie | ssl-session-id} 
SGOS# (config forwarding host^alias) host-affinity other {default | 
none | client- ip-address } 

SGOS# (config forwarding host^alias) load-balance method {default | 
least-connections | none | round- robin} 

SGOS# (config forwarding host_alias) no {ftp | http | https | mms | 
rtsp | ssl-verify-server | tcp | telnet} 

SGOS# (config forwarding host_alias) proxy | server 
SGOS# (config forwarding host_alias) ssl-verify-server 
SGOS# (config forwarding hostalias) view 
SGOS# (config forwarding) edit group_alias 

SGOS# (config forwarding group^alias) {add | remove} host_alias 
SGOS# (config forwarding groupalias) exit 

SGOS# (config forwarding group_alias) host-affinity http {default | 
none | client- ip-address | accelerator-cookie} 

SGOS# (config forwarding group^alias) host-affinity ssl {default I 
none | client- ip-address | accelerator-cookie | ssl-session-id} 
SGOS# (config forwarding group^alias) host-affinity other {default | 
none | client- ip-address } 

SGOS# (config forwarding group_alias) load-balance {default | 
domain-hash | least-connections | none | round-robin | url-hash} 

SGOS# (config forwarding group_alias) view 
SGOS# (config forwarding) exit 

SGOS# (config forwarding) failure-mode {closed | open} 

SGOS# (config forwarding) host-affinity http {default I none | client- 
ip-address | accelerator-cookie} host_or_group_alias 

SGOS# (config forwarding) host-affinity http {none | client-ip-address 
| accelerator-cookie} 

SGOS# (config forwarding) host-affinity ssl {default | none | client- 
ip-address | accelerator-cookie | ssl-session-id} host_or_group_alias 
SGOS# (config forwarding) host-affinity ssl {none | client-ip-address | 
accelerator-cookie | ssl-session-id} 

SGOS# (config forwarding) host-affinity other {default ] none | client- 
ip-address} host_or_group_alias 

SGOS# (config forwarding) host-affinity other {none | client- ip- 
address } 

SGOS# (config forwarding) host-affinity timeout minutes 
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SGOS# (config forwarding) integrated-host- timeout minutes 

SGOS# (config forwarding) load-balance group {default I none | domain- 

hash | url-hash | round- robin | least-connections} group_alias 

SGOS# (config forwarding) load-balance group {none | domain-hash | url- 

hash | round-robin | least-connections} 



default | none | round- 
none | round-robin | 



SGOS# (config forwarding) load-balance host 
robin | least-connections} host_alias 
SGOS# (config forwarding) load-balance host 
least-connections } 

SGOS# (config forwarding) no path 
SGOS# (config forwarding) path url 

SGOS# (config forwarding) sequence add host_or_group_alias 
SGOS# (config forwarding) sequence clear 

SGOS# (config forwarding) sequence demote host_or_group_alias 
SGOS# (config forwarding) sequence promote host_or_group_alias 
SGOS# (config forwarding) sequence remove host_or_group_alias 
SGOS# (config forwarding) view 



Statistics 

To view forwarding statistics, select Statistics > Advanced > Forwarding. 
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Section D: Using Forwarding Directives to Create an Installable List 

You can use directives instead of using the Management Console or CLI to configure 
forwarding. Note that the Management Console offers the easiest method of 
configuration. Using directives, you can: 

□ Create the forwarding hosts and groups 

□ Provide load balancing and host affinity 



Table 8-2. Forwarding Directives 



Directive 


Meaning 


See 


fwd fail 


Determines whether the 
forwarding host should fail open 
or fail closed if an operation does 
not succeed. 


"Setting Fail Open/Closed and 
Host Timeout Values" on page 
116. 


fwd host 


Creates a forwarding host and sets 
configuration parameters for it, 
including protocols and ports. 


"Creating Forwarding Hosts" 
on page 115. 


group 


Creates a forwarding group and 
identifies members of the group. 


"Creating Forwarding Groups 
Using Directives" on page 116. 


host affinity 


Directs multiple connections by a 
single user to the same group 
member. 


"Configuring Host Affinity 
Directives" on page 117. 


integrated host 
timeout 


Manages an origin content server 
that has been added to the health 
check list. The host ages out after 
being idle for the specified time. 


"Setting Fail Open/ Closed and 
Host Timeout Values" on page 
116. 


load balance 


Manages the load among 
forwarding hosts in a group, or 
among multiple IP addresses of a 
host. 


"Configuring Load-Balancing 
Directives" on page 117. 


sequence 


Sets the default sequence to the 
space separated list of one or more 
forwarding host and group 
aliases. (The default sequence is 
the default forwarding rule, used 
for all requests lacking policy 
instructions.) 


"Creating a Default Sequence” 
on page 118. 



Creating Forwarding Host and Group Directives 

A forwarding host directive creates a host along with all its parameters. You can include a 
group that the forwarding host belongs to. 

A group directive creates a group and identifies group members. For more information on 
group directives, skip to "Creating Forwarding Groups Using Directives" on page 116. 
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Creating Forwarding Hosts 

To create a forwarding host, choose the protocols you want to use and add the forwarding 
host to a group, enter the following into your installable list. Create a fwd host directive 
for each forwarding host you want to create. 

fwd_host host_alias hostname [http [=port] ] [https [=port] ] [ ftp [=port] ] 

[mms [=port] ] [ rtsp [=port] ] [tcp=port] [telnet [=port ] ] [ssl-verify- 

server[=yes | =no] ] [group =group_name [server | proxy]] 



Table 8-3. Commands to Create Forwarding Host and Group Directives 



host alias 




This is the alias for use in policy. Define a meaningful 
name. 


hostname 




The name of the host domain, such 
www . bluecoat . com, or its IP address. 


http 

https 

ftp 

mms 

rtsp 

telnet 


=port 


At least one protocol must be selected 
HTTPS and Telnet cannot be used with a proxy. 

Note that HTTPS refers to terminated HTTPS, so it is 
used only for a server. 


tcp 


=port 


If you choose to add a TCP protocol, a TCP port must 
be specified. 

TCP protocols are not allowed if the host is a proxy. 


ssl-verif y- 
server 


=yes | =no 


Sets SSL to specify that the SG appliance checks the CA 
certificate of the upstream server. 

The default for ssl-verify-server is yes. This can 
be overridden in the SSL layer in policy 
To disable this feature, you must specify ssl-verify- 
server=no in the installable list or CLI. In other 
words, you can configure ssl-verif y-server=yes 
in three ways: do nothing (yes is the default), specify 
ssl-verif y-server=no, or specify ssl-verify- 
server=yes . 


group 


=group name 


Specifies the group (or server farm or group of proxies) 
to which this host belongs. If this is the first mention of 
the group group name then that group is 
automatically created with this host as its first member. 

The SG appliance uses load balancing to evenly 
distribute forwarding requests to the origin servers or 
group of proxies. 


server | proxy 




server specifies to use the relative path for URLs in 
the HTTP header because the next hop is a Web server, 
not a proxy server. The default is proxy. 



Example 

fwd_host www.bluecoatl.com 10.25.36.48 ssl-verif y-server=no 
group=bluecoat 
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Creating Forwarding Groups Using Directives 

The forwarding groups directive has the following syntax: 

group group_name host_alias_l host_alias_2 . . . 

where group_name is the name of the group, and host_alias__l, host_alias_2, and so 
forth are the forwarding hosts you are assigning to the forwarding group. 

Forwarding host parameters are configured through the forwarding host directives. 

Setting Special Parameters 

After you configure the forwarding hosts and groups, you might need to set other special 
parameters to fine tune the hosts. You can configure the following settings: 

□ "Setting Fail Open/ Closed and Flost Timeout Values" . 

□ "Configuring Load-Balancing Directives" on page 117. 

□ "Configuring Flost Affinity Directives" on page 117. 

Setting Fail Open/Closed and Host Timeout Values 

Using directives, you can determine if the forwarding host fails open or closed, if an 
operation does not succeed, and the interval it takes for integrated hosts to be aged out. 

An integrated host is an Origin Content Server (OCS) that has been added to the health 
check list. If the policy property integrate_new_hosts applies to a forwarding request as 
a result of matching the integrate new hosts property., the SG appliance makes a note 
of each OCS and starts health checking to help future accesses to those systems. If the host 
is idle for the interval you specify, it is aged out. Sixty minutes is the default interval. 

The syntax is: 

fwd_fail {open | closed} 
integrated host timeout minutes 



Table 8-4. Commands to Set Fail Open/Closed and Host Timeout Values 



fwd fail 


{open | 
closed} 


Determines whether the forwarding host should 
fail open or fail closed if an operation does not 
succeed. Fail open is a security risk, and fail 
closed is the default if no setting is specified. 
This setting can be overridden by policy, (using 
the forward, fail open (yes | no) property). 


integrated host timeout 


minutes 


An OCS that has been added to the health check 
list is called an integrated host. The host ages out 
after being idle for the specified time. 



Examples 

fwd_fail open 

integrated_host_timeout 90 
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Configuring Load-Balancing Directives 

Load balancing shares the load among a set of IP addresses, whether a group or a host 
with multiple IP addresses. 

The syntax is: 

load_balance group {none | domain-hash | ur 1-hash | round-robin | 
least-connections} [ group^alias ] 

load_balance host {none | round-robin | least-connections} 

[ host_alias ] 



Table 8-5. Load Balancing Directives 



Command 


Suboptions 


Description 


load balance 
group 


{none | domain-hash | url- 
hash | round-robin | 
least-connections } 

[group alias] 


If you use group for load balancing, 
you can set the suboption to none or 
choose another method. If you do not 
specify a group, the settings apply as the 
default for all groups. 


load balance 
host 


{none | round-robin | 
least-connections } 

[ host alias] 


If you use host for load balancing, you 
can set the suboption to none or choose 
another method. If you do not specify a 
host, the settings apply as the default for 
all hosts. 



Example 

load_balance host least_connections 

Configuring Host Affinity Directives 

Host affinity is the attempt to direct multiple connections by a single user to the same 
group member. 

The syntax is: 

host_af finity http {none | client-ip-address | accelerator-cookie} 

[ host_or_group_alias ] 

host_af finity ssl {none | client-ip-address | accelerator-cookie | 
s si -session- id} [ host__or_group_alias ] 

host_af finity other {none | client-ip-address} [ host_or_group_alias ] 
host_af finity timeout minutes 



Table 8-6. Commands to Configure Host Affinity Directives 



Command 


Suboption 


Description 


host affinity 
http 


{accelerator-cookie I 
client-ip-address | none} 
[ host or group alias] 


Determines which HTTP host-affinity 
method to use (accelerator cookie 
or client-ip-address), or you can 
specify none. If you do not specify a 
host or group, the settings apply as the 
default for all hosts or groups. 
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Table 8-6. Commands to Configure Host Affinity Directives (Continued) 



Command 


Suboption 


Description 


host affinity 
ssl 


{accelerator-cookie I 
client-ip-address | none 
I ssl-session-id} 

[ host or group alias] 


Determines which SSL host-affinity 
method to use (accelerator cookie, 
client-ip-address, or ssl- 
session-id), or you can specify none. 
If you do not specify a host or group, the 
settings apply as the default for all hosts 
or groups. 


host affinity 
other 


{none | client-ip- 
address } 

[ host or group alias] 


Determines whether client-ip- 
address mode is used with TCP 
tunnels or Telnet. 


host affinity 
timeout 


minutes 


Determines how long a user's IP 
address, SSL ID, or cookie remains valid 
when idle 



Example 

host_af finity ssl_method 10.25.36.48 
host_af finity timeout 5 

Creating a Default Sequence 

The default sequence is the default forwarding rule, used for all requests lacking policy 
instructions. Failover is supported if the sequence (only one is allowed) has more than one 
member. 



Note: The default sequence is completely overridden by policy. 



A default failover sequence works by allowing healthy hosts to take over for an unhealthy 
host (one that is failing its DNS resolution or its health check). The sequence specifies the 
order of failover, with the second host taking over for the first host, the third taking over 
for the second, and so on). 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your 
settings. 

This configuration is generally created and managed through policy. If no forwarding 
policy applies, you can create a default sequence through the CLI. This single default 
sequence consists of a single default host (or group) plus one or more hosts to use if the 
preceding ones are unhealthy. 

The syntax is: 

sequence alias_list 

where alias_list is a space-separated list of one or more forwarding host and 
group aliases. 

Example 

sequence bluecoat 
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Creating a Forwarding Installable List 

You can create and install the forwarding installable list using one of the following 
methods: 

□ Text Editor, which allows you to enter the installable list of directives (or copy and 
paste the contents of an already-created file) directly onto the appliance. 

□ A local file, created on your system; the SG appliance can browse to the file and install 
it. 

□ A remote URL, where you placed an already-created file on an FTP or HTTP server to 
be downloaded to the SG appliance. 

□ CLI inline command. 

When the Forwarding Installable List is installed, it replaces the forwarding configuration 
on the SG appliance. The configuration remains in effect until overwritten by another 
installable list; the configuration can be modified or overwritten using CLI commands. 



Note: During the time that a forwarding installable list is being compiled and installed, 
forwarding might not be available. Any transactions that come into the SG appliance 
during this time might not be forwarded properly. 



Installation of forwarding installable lists should be done outside peak traffic times. 

To create a forwarding installable list: 

1. Select Configuration > Forwarding > Install Forwarding File. 

2. From the drop-down list, select the method to use to install the forwarding installable 
list; click Install. 



Note: A message is written to the event log when you install a list through the SGOS 
software. 



• Remote URL: 

Enter the fully-qualified URL, including the filename, where the installable list is 
located. To view the file before installing it, click View. Click Install. Examine the 
installation status that displays; click OK. 

• Local File: 

Click Browse to display the Local File Browse window. Browse for the installable 
list file on the local system. Open it and click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation 
is complete, a results window opens. View the results, close the window, 
click Close. 
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Note: The Management Console text editor is a way to enter an installable list 
for forwarding. It is not a way to enter CLI commands. The directives are 
understood only by the installable list parser for forwarding. 



3. Click Apply. 



Note: You can create forwarding settings using the CLI #inline forwarding command. 
You can use any of the forwarding directives. 

For more information on using inline commands, refer to Volume 11: Command Line 
Reference. 



To delete forwarding settings on the SG appliance: 

From the (conf ig) prompt, enter the following commands to delete a host, a group, or 
all hosts and groups from the forwarding configuration: 

SGOS# (config) forwarding 

SGOS# (config forwarding) delete {all | group group_name | host 
host alias} 



Note: : Any host or group in the default sequence (or the DRTR service configuration) is 
considered in use by policy. As a result, if you try to delete a host or group while it is in 
the default sequence or DRTR service configuration, you will receive an error message. 
You must remove the host /group from the sequence or service first, then delete. 
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ICP is a communication protocol for caches. It allows a cache (not necessarily a SG 
appliance) to query other caches for an object, without actually requesting the object. By 
using ICP, the cache can determine if the object is available from a neighboring cache, 
and which cache provides the fastest response. 



Note: The SG appliance (assuming ICP is configured) does ICP queries only if no 
forwarding host or SOCKS gateway is identified as an upstream target. If ICP is used by 
the appliance, it prompts other cache devices for the item, and upon a positive response 
re-directs the upstream request to that cache device instead of the content origin server. 



Only use ICP if you have ICP hosts available or to have the SG appliance support 
requests from other ICP hosts. 

By default, the ICP protocol requires the requesting host to wait up to two seconds for 
all ICP hosts to respond to the request for an object (the time is configurable). 

If the ICP service is configured and running, the service is used if no forwarding or 
SOCKS gateway target was specified. In other words, the policy rule icp (yes) is the 
default, assuming that the ICP service is available. You can disable ICP with the policy 
rule icp (no) to control ICP queries for requests. 

Configuring ICP 

An ICP hierarchy is comprised of a group of caches, with defined parent and sibling 
relationships. A cache parent is one that can return the object if it is in the cache, or 
request the object from the source on behalf of the requester if the object is not in the 
cache. A cache sibling is a device that can only return the object if it is in the cache. One 
cache acting as a parent can also act as a sibling to other cache devices. 

□ When an object is not cached, the cache device sends an ICP query to its neighbors 
(parents and siblings) to see if any of its peers holds the object. 

□ Each neighbor that holds the requested object returns an ICP HIT reply. 

□ Each neighbor that does not hold the object returns an ICP MISS reply. 

Based on the responses, the cache can determine where to request the object: from one 
of its neighbors or from the source. If an icp hit reply is received, the request is sent to 
the host that returned the first reply. If no ICP HIT reply is received, the request is 
forwarded to the first parent that replied. If no parents respond or are configured, the 
request is made directly to the source. 

Using ICP Configuration Directives to Create an Installable List 

To configure ICP you must create an installable list and load it on the SG appliance. The 
ICP protocol contains a number of directives, commands used to create a list that can be 
installed on the SG appliance. 

For information on installing the file itself, see "Creating an ICP Installable List" on 
page 125. 

The ICP configuration includes directives that: 
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□ Name the ICP hosts 

□ Restrict ICP access to only these hosts 
Available directives are listed in Table 9-1 . 



Table 9-1 . ICP Directives 



Directive 


Meaning 


Where used 


icp host 


The icp host directive describes cache peers in the 
hierarchy. There should be one entry for each SG 
appliance you want to use. 


Names the ICP hosts. See 
"Naming the IP Hosts" on 
page 123. 


icp access domain 


The icp access domain directive is used to control 
which ICP queries are accepted. The 
icp access domain directive requires a reverse DNS 
lookup of each ICP query to validate the IP address. 


Restricts access. See 
"Restricting Access" on 
page 123. 


icp access ip 


The icp access ip directive works like the 
icp access domain command, except that you can 
specify an IP address and subnet mask rather than a 
domain. 


Restricts access. 

See "Restricting Access" on 
page 123. 


icp port 


The icp port directive sets the port the SG appliance 
uses to listen for ICP requests. The default port is 3130. 
If you set the port to 0, ICP is disabled. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 124. 


neighbor timeout 


The neighbor timeout directive sets the number of 
seconds the SG appliance waits for ICP replies. When 
the cache device sends an ICP request, it waits for all 
hosts to reply or for the neighbor timeout to expire. 
The default timeout is two seconds. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 124. 


icp failcount 


The icp failcount directive sets the number of 
consecutive failures the cache device can receive before 
considering the ICP host as failed. By default, the ICP 
failure count is set to 20. Each time a request fails, the 
failure count is incremented. When a request succeeds, 
the failure count is reset to zero. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 124. 


http failcount 


The http failcount directive sets the number of 
consecutive failures the cache device can receive before 
considering the HTTP host as failed. By default, the 
HTTP failure count is set to five. The failure count 
increments each time a request fails. When a request 
succeeds, the failure count is reset to zero. When an 
HTTP host fails, the cache device waits five minutes 
before attempting to use it again as a forwarding target. 
If the next request fails, the cache device continues to 
wait five minutes between attempts until the cache 
becomes available. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 124. 


host fail notify 


The host fail notify directive tells the cache 
device to send event notification e-mail when a connect 
fails persistently. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 124. 


host recover 
notify 


The host recover notify directive tells the cache 
device to send event notification e-mail when a failed 
host recovers. 


Connects to other ICP hosts. 
See "Connecting to Other 
ICP Hosts" on page 124. 
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Naming the IP Hosts 

The icp host directive describes peers in the hierarchy. One entry is required for each SG 
appliance you want to use. 

icp_host hostname peertype HTTPport ICPport [default | backup | 
feeder] 



Table 9-2. ICP_host Directive 



Command 


Suboptions 


Description 


hostname 




The host name of the SG appliance. 


peertype 


{parent | 
sibling} 


Relationship of the SG appliance to the cache device you are configuring. 


HTTPport 




TCP port where the SG appliance accepts HTTP requests. The common HTTP 
port is 80 or 8080. 


ICPport 




UDP port where the SG appliance accepts ICP requests. The common ICP port 
is 3130. 


default 




If specified, designates a SG host parent to be the default ICP parent. If no ICP 
reply is received, all requests are forwarded to the default parent. 


backup 




If specified, designates the cache device host parent to be the backup default 
ICP parent. If the default parent is not available, the cache device uses the 
backup default parent. 


feeder 




If specified, designates the SG host sibling as a feeder-type host, using ICP 
request loops to populate the appliance. 



The following are sample icp host directives that can be entered into the ICP 
configuration: 



; Define 
icp_host 
icp_host 
icp_host 
icp_host 
icp_host 



ICP parent and si 
cml . bluecoat . com 
cm2 .bluecoat . com 
cm3 .bluecoat . com 
cm4 .bluecoat . com 
cm5 .bluecoat . com 



bling hosts. 

parent 8080 3130 default 
sibling 8080 3130 
sibling 8080 3130 
sibling 8080 3130 
parent 8080 3130 



Restricting Access 

You can restrict access to SG appliances acting as caches by other ICP hosts using the 
icp access domain and icp access ip directives. By default, when ICP is configured, 
all ICP hosts are allowed access. You should deny access to all domains other than the ICP 
hosts you want to use. 

icp_access_domain Directive 

The icp access domain directive defines which hosts can request objects from the Web 
cache using ICP. The default action is to allow all requests. When you use 
icp access domain, each ICP query requires a reverse DNS lookup to validate the IP 
address. Depending on the number of ICP requests, these lookups can consume SG 
appliance resources. 

icp_access_domain {allow | deny} domain 
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Table 9-3. ICP_Access_Domain Directive 



Directive Option 


Description 


allow | deny 


Allows or denies ICP queries from neighbors that match the domain 
specification. 


domain 


The domain to match. All ICP queries from neighbors that match the 
specified domain are handled by the host. The special domain of all 
defines the default action when there is no domain match. 



The following are sample icp access domain directives to be entered into the 



ICP configuration: 

; allow ICP access to this Blue Coat Systems SG Appliance from the 
; bluecoat.com domain 

icp_access_domain allow bluecoat.com 
icp_access_domain deny all 

; the deny all option should always be specified to deny all other 
; domains 

icp_access_ip Directive 

The icp_access_ip directive works like the icp access domain command, except that 
you can specify an IP address and subnet mask rather than a domain. The following 
describes the parameters for the icp access ip command: 

icp_access_ip {allow | deny} subnet mask 



Table 9-4. ICAP_Access_IP Directive 



Directive Option 


Description 


allow | deny 


Allow or deny ICP queries from neighbors that match the address 
specification. 


address/subnet mask 


The address and subnet mask to match. All ICP queries that match 
the specified address are handled by the ICP host. The special 
address of 0 . 0 . 0 . 0 defines the default action when there is no 
address match. 



The following are sample icp_access ip directives to be entered into the ICP 
configuration: 

; allow ICP access to this Blue Coat Systems SG Appliance from the 
local subnet 

icp_access_ip allow 192.168.10.0/255.255.255.0 
icp_access_ip deny 10.25.36.47 

; the deny all option should always be specified to deny all other 
domains 

Connecting to Other ICP Hosts 

In addition to the ICP directives described in the sections above, you can specify the 
following directives in the ICP configuration: 

icp_p° r t 0 
neighbor_timeout 2 
icp_f ailcount 20 
http_failcount 5 
host_fail_notify on 
host_recover_notif y on 
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Table 9-5. Connecting to Other ICP Hosts 



Directive 


Description 


icp port 


The default port is 3130. If you set the port to 0, ICP is disabled. 


neighbor timeout 


When the cache device sends an ICP request, it waits for all hosts to 
reply or for the neighbor timeout to expire. The default timeout is 
two seconds. 


http failcount 


By default, the HTTP failure count is set to five. The failure count 
increments each time a request fails. When a request succeeds, the 
failure count resets to zero. When an HTTP host fails, the cache device 
waits five minutes before attempting to use it again as a forwarding 
target. 


icp failcount 


By default, the ICP failure count is set to 20. Each time a request fails, 
the failure count is incremented. When a request succeeds, the failure 
count is reset to zero. 


host fail notify 


on tells the cache to send event notification e-mail when a connect fails 
persistently; off disables this setting. 


host recover 
notify 


on tells the cache to send event notification e-mail when a failed host 
recovers; off disables this setting. 



Creating an ICP Installable List 

You can create the ICP installable list using one of the following methods: 

□ Text Editor, which allows you to enter directives (or copy and paste the contents of an 
already-created file) directly onto the SG appliance. 

□ Local file, installed on your system; the SG appliance can browse to the file and install 
it. 

□ A remote URL, where you place an already-created file on an FTP or HTTP server to be 
downloaded to the SG appliance. 

□ The CLI inline command. 

When the ICP installable list is created and installed, it overwrites any ICP settings on the 
SG appliance. 

To create an ICP installable list: 

1. Select Configuration > Forwarding > ICP. 

2. From the drop-down list, select the method you want to use to install the ICP 
configuration; then click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the configuration is 
located. To view the file before installing it, click View. Click Install. Examine the 
installation status that displays; click OK. 

• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the 
local system. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 
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• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 

3. Click Apply to commit the changes to the SG appliance. 



Note: You can create ICP settings using the CLI inline commands. 

For more information on using inline commands, refer to Volume 11: Command Line 
Reference. 



Enabling ICP 

Before ICP can be used in the SG environment: 

□ ICP must be running 

□ At least one forwarding host must be configured 

ICP can be enabled or disabled through the policy rule i cp . The default is i cp ( ye s ) . You 
can disable ICP with the policy rule icp (no) to control ICP queries for requests. 
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The Routing Information Protocol (RIP) is designed to select the fastest route to a 
destination. RIP support is built into the SG appliance, and is configured by created and 
installing an RIP configuration text file onto the device. 

The Blue Coat RIP implementation also supports advertising default gateways. Default 
routes added by RIP are treated the same as the static default routes; that is, the default 
route load balancing schemes apply to the default routes from RIP as well. 

This chapter discusses: 

□ "Installing RIP Configuration Files" on page 127 

□ "Configuring Advertising Default Routes" on page 128 

□ "RIP Commands" on page 129 

□ "RIP Parameters" on page 130 

□ "SG-Specific RIP Parameters" on page 131 

□ "Using Passwords with RIP" on page 131 

Installing RIP Configuration Files 

No RIP configuration file is shipped with the appliance. For commands that can be 
entered into the RIP configuration file, see "RIP Commands" on page 129. 

After creating an RIP configuration file, install it using one of the following methods: 

□ Using the Text Editor, which allows you to enter settings (or copy and paste the 
contents of an already-created file) directly onto the appliance. 

□ Creating a local file on your local system; the SG appliance can browse to the file and 
install it. 

□ Using a remote URL, where you place an already-created file on an FTP or HTTP 
server to be downloaded to the SG appliance. 

□ Using the CLI inline rip-settings command, which allows you to paste the RIP 
settings into the CLI. 

□ Using the CLI rip commands, which require that you place an already-created file 
on an FTP or HTTP server and enter the URL into the CLI. You can also enable or 
disable RIP with these commands. 

To install an RIP configuration file: 



Note: When entering RIP settings that affect current settings (for example, when 
switching from ripvl to ripv2), disable RIP before you change the settings; re-enable 
RIP when you have finished. 



1. Select Configuration > Network > Routing > RIP. 

2. To display the current RIP settings, routes, or source, click one or all of the View RIP 
buttons. 
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3. In the Install RIP Setting from the drop-down list, select the method used to install the 
routing table; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the routing table is 
located. To view the file before installing it, click View. Click Install. To view the 
installation results, click Results; close the window when you are finished. Click 

OK. 

• Local File: 

Click Browse to display the Local File Browse window. Browse for the file on the 
local system. Open it and click Install. When the installation is complete, a results 
window opens. View the results and close the window. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, and click 

OK. 

4. Click Apply to commit the changes to the SG appliance. 

5. Select Enable RIP. 

6. Click Apply. 

Related CLI Syntax to Configure RIP 

SGOS# (config) rip {disable | enable} 

□ To enter a path to a remote URL where you have placed an already-created RIP 
configuration file, enter the following commands at the (config) command prompt: 

SGOS# (config) rip path url 
SGOS# (config) load rip-settings 

□ To paste an RIP configuration directly into the CLI, enter the following command at 
the (config) command prompt: 

SGOS# (config) inline rip-settings end-of-file_marker 



Configuring Advertising Default Routes 

Default routes advertisements are treated the same as the static default routes; that is, the 
default route load balancing schemes also apply to the default routes from RIP. 

By default, RIP ignores the default routes advertisement. You can change the default from 
disable to enable and set the preference group and weight through the CLI only. 

To enable and configure advertising default gateway routes: 

1. At the (config) command prompt: 

SGOS# (config) rip default- route enable 

SGOS# (config) rip default- route group group_number 
SGOS# (config) rip default- route weight weight_number 

Where group_number defaults to l,and weight^number defaults to 100, the same 
as the static default route set by the ip-default-gateway command. 
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2. (Optional) To view the default advertising routes, enter: 

SGOS# (config) show rip default-route 

RIP default route settings: 

Enabled: Yes 

Preference group: 3 

Weight: 30 

RIP Commands 

You can place any of the commands below into a Routing Information Protocol (RIP) 
configuration text file. You cannot edit a RIP file through the command line, but you can 
overwrite a RIP file using the inline rip-settings command. 

Once the file is complete, place it on an HTTP or FTP server accessible to the SG appliance 
and download it. 



net 



net Nname [ /mask] gateway Gname metric Value {passive | active | 
external } 



Table 1 0-1 . net Commands 



Parameters 


Description 


Nname 


Name of the destination network. It can be a symbolic network 
name, or an Internet address specified in dot notation. 


/mask 


Optional number between 1 and 32 indicating the netmask 
associated with Nname. 


Gname 


Name or address of the gateway to which RIP responses should be 
forwarded. 


Value 


The hop count to the destination host or network. A net Nname/ 32 
specification is equivalent to the host Hname command. 


passive I active I 
external 


Specifies whether the gateway is treated as passive or active, or 
whether the gateway is external to the scope of the RIP protocol. 



host 



host Hname gateway Gname metric Value {passive | active | external} 



Table 10-2. host Commands 



Parameters 


Description 


Hname 


Name of the destination network. It can be a symbolic network 
name, or an Internet address specified in dot notation. 


Gname 


Name or address of the gateway to which RIP responses should be 
forwarded. It can be a symbolic network name, or an Internet 
address specified in dot notation. 


Value 


The hop count to the destination host or network. A net Nname/ 32 
specification is equivalent to the host Hname command. 


passive | active | 
external 


Specifies whether the gateway is treated as passive or active, or 
whether the gateway is external to the scope of the RIP protocol. 
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RIP Parameters 

Lines that do not start with net or host commands must consist of one or more of the 
following parameter settings, separated by commas or blank spaces: 



Table 10-3. RIP Parameters 



Parameters 


Description 


if= [0 | 1 | 2 | 3] 


Specifies that the other parameters on the line apply to the interface numbered 0,1,2, 
or 3 in SGOS terms. 


passwd=XXX 


Specifies an RIPv2 password included on all RlPv2 responses sent and checked on all 
RIPv2 responses received. The password must not contain any blanks, tab characters, 
commas or characters. 


no ag 


Turns off aggregation of subnets in RIPvl and RIPv2 responses. 


no super ag 


Turns off aggregation of networks into supernets in RIPv2 responses. 


passive 


Marks the interface to not be advertised in updates sent through other interfaces, and 
turns off all RIP and router discovery through the interface. 


no rip 


Disables all RIP processing on the specified interface. 


no ripvl in 


Causes RIPvl received responses to be ignored. 


no ripv2 in 


Causes RIPv2 received responses to be ignored. 


ripv2 out 


Turns off RIPvl output and causes RIPv2 advertisements to be multicast when 
possible. 


r ipv2 


Is equivalent to no ripvl in and no ripvl out. This parameter is set by default. 


no rdisc 


Disables the Internet Router Discovery Protocol. This parameter is set by default. 


no solicit 


Disables the transmission of Router Discovery Solicitations. 


send solicit 


Specifies that Router Discovery solicitations should be sent, even on point-to-point 
links, which by default only listen to Router Discovery messages. 


no rdisc adv 


Disables the transmission of Router Discovery Advertisements. 


rdisc adv 


Specifies that Router Discovery Advertisements should be sent, even on point-to- 
point links, which by default only listen to Router Discovery messages. 


beast rdisc 


Specifies that Router Discovery packets should be broadcast instead of multicast. 


rdisc pref=N 


Sets the preference in Router Discovery Advertisements to the integer N. 


rdisc interval=N 


Sets the nominal interval with which Router Discovery Advertisements are 
transmitted to N seconds and their lifetime to 3*N. 


trust gateway=rname 


Causes RIP packets from that router and other routers named in other trust_gateway 
keywords to be accept, and packets from other routers to be ignored. 


redirect ok 


Causes RIP to allow ICMP Redirect messages when the system is acting as a router 
and forwarding packets. Otherwise, ICMP Redirect messages are overridden. 
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SG-Specific RIP Parameters 

The following RIP parameters are unique to SG configurations: 



Table 10-4. SG-Specific RIP Parameters 



Parameters 


Description 


supply routing info 


-s option: 


-or- 


Supplying this option forces routers to supply routing 
information whether it is acting as an Internetwork router or not. 


advertise routes 


This is the default if multiple network interfaces are present or if a 
point-to-point link is in use. 

-g option: 

This flag is used on Internetwork routers to offer a route to the 
'default' destination. This is typically used on a gateway to the 
Internet, or on a gateway that uses another routing protocol 
whose routes are not reported to other local routers. 

-h option: 

Suppress extra host routes advertise host route 

-m option: 

Advertise host route on multi-homed hosts 
-A option: 

Ignore_authentication / / 


no supply 


-q option: 


routing info 


opposite of -s. 


no rip out 


Disables the transmission of all RIP packets. This setting is the 
default. 


no ripvl out 


Disables the transmission of RIPvl packets. 


no ripv2 out 


Disables the transmission of RIPv2 packets. 


rip out 


Enables the transmission of RIPvl packets. 


ripvl out 


Enables the transmission of RIPvl packets. 


rdisc 


Enables the transmission of Router Discovery Advertisements. 


ripvl 


Causes RlPvl packets to be sent. 


ripvl in 


Causes RIPvl received responses to be handled. 



Using Passwords with RIP 

The first password specified for an interface is used for output. All passwords pertaining 
to an interface are accepted on input. For example, with the following settings: 

if=0 passwd=aaa 
if=l passwd=bbb 
passwd=ccc 

Interface 0 accepts passwords aaa and ccc, and transmits using password aaa. Interface 1 
accepts passwords bbb and ccc, and transmits using password bbb. The other interfaces 
accept and transmit the password ccc . 
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You can configure the SGOS software to monitor RADIUS accounting messages and to 
maintain a session table based on the information in these messages. The session table 
can then be used for logging or authentication. 

You can also, optionally, configure multiple appliances to act as a session monitor 
cluster. The session table is then replicated to all members of the cluster. 

Once configured and enabled, the session monitor maintains a session table that 
records which sessions are currently active and the user identity for each session. 



Configuring the Session Monitor 

Three steps are required to configure the session monitor: 

□ Configure the RADIUS accounting protocol parameters for the session monitor. 

□ (Optional) Configure the session monitor cluster. 

□ Configure the session monitor parameters. 



Configuring the RADIUS Accounting Protocol Parameters 

The configuration commands to create the RADIUS accounting protocol parameters 
can only be done through the CLI. If you are using session-monitor clustering, the 
commands must be invoked on each system in an already-existing failover group. (For 
information on configuring a failover group, see Chapter 7: "Configuring Failover'on 
page 97.) 



To configure the RADIUS accounting protocol parameters: 

□ To enter configuration mode: 

SGOS# (config) session-monitor 



□ The following subcommands are available: 

SGOS# (config session-monitor) radius acct-listen-port port_number 

SGOS# (config session-monitor) radius authentication {enable | 
disable } 



SGOS# (config session-monitor) radius encrypted-shared-secret 

encrypted^secret 



SGOS# (config session-monitor) 



radius no encrypted-shared-secret 



SGOS# (config session-monitor) 
SGOS# (config session-monitor) 



radius response {enable | disable} 
radius shared-secret plaintext_secret 
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Table 11-1. Session Monitor Accounting Command Descriptions 



Command 


Option 


Description 


radius acct-listen-port 


port number 


The port number where the SG appliance listens for 
accounting messages 


radius authentication 


enable | disable 


Enable or disable (the default) the authentication of 
RADIUS messages using the shared secret. Note 
that the shared secret must be configured before 
authentication is enabled. 


radius encrypted-shared- 
secret 


encrypted shared 
secret 


Specify the shared secret (in encrypted form) used 
for RADIUS protocol authentication. The secret is 
decrypted using the configuration-passwords-key. 


radius no shared-secret 




Clears the shared secret used for RADIUS protocol 
authentication. 


radius response 


enable | disable 


Enable (the default) or disable generation of 
RADIUS responses. 


radius shared-secret 


plaintext secret 


Specify the shared secret used for RAIDUS protocol 
in plaintext. 



Configuring a Session Monitor Cluster 

Configuring a session monitor cluster is optional. When a session monitor cluster is 
enabled, the session table is replicated to all members of the cluster. The cluster members 
are the SG appliances that are configured as part of the failover group referenced in the 
session monitor cluster configuration. The failover group must be configured before the 
session monitor cluster. (For information on configuring a failover group, see Chapter 7: 
"Configuring Failover'on page 97.) 

To replicate the session table to all the members of a failover group, you can use the 
following commands. 



Note: When using a session monitor cluster, the RADIUS client must be configured to 
send the RADIUS accounting messages to the failover group's virtual IP address. 



Proxy traffic can be routed to any of the machines in the cluster. 



Note: Each member of the failover group must configured with the cluster commands to 
maintain the session table for RADIUS accounting messages. 



To configure session monitor cluster parameters: 

SGOS# (config) session-monitor 



□ 



The following subcommands are available: 

SGOS# (config session-monitor) cluster 
SGOS# (config session-monitor) cluster 

SGOS# (config session-monitor) cluster 
SGOS# (config session-monitor) cluster 
SGOS# (config session-monitor) cluster 



{enable | disable} 
group-address IP_address 

port port_number 

grace-period seconds 
synchronization-delay seconds 
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Table 1 1 -2. Session Monitor Cluster Command Descriptions 



Command 


Option 


Description 


cluster 


enable I 
disable 


Enable or disable (the default) clustering on a failover group. 
The group address must be set before the cluster can be 
enabled. 


cluster group-address 
I no group-address 


IP address 


Set or clear (the default) the failover group IP address. This 
must be an existing failover group address. 


cluster port 


port number 


Set the TCP/IP port for the session replication control. The 
default is 55555. 


cluster 

synchronization-delay 


seconds 


Set the maximum time to wait for session table 
synchronization. The default is zero; the range is from 0 to 2 
A 31 -1 seconds. During this time evaluation of 
$ (session, username ) is delayed, so proxy traffic might 
also be delayed. 


cluster grace-period 


seconds 


Set the time to keep session transactions in memory while 
waiting for slave logins. This can be set to allow session table 
synchronization to occur after the synchronization-delay has 
expired. The default is 30 seconds; the range is 0 to 2 A 31-1 
seconds. 



Configuring the Session Monitor 

The session monitor commands set up session monitoring behavior. If using session- 
monitor clustering, these commands must be invoked on all systems in the failover group. 

To configure the session monitor: 

1. At the (config) prompt: 

SGOS# (config) session-monitor 

SGOS# (config session-monitor) disable | enable 
SGOS# (config session-monitor) max-entries integer 
SGOS# (config session-monitor) timeout minutes 



Table 11-3. Session Monitor Configuration Command Descriptions 



Command 


Option 


Description 


enable | disable 




Enable or disable (the default) session monitoring 


max entries 


integer 


The maximum number of entries in the session table. 
The default is 500,000; the range is from 1 to 2,000,000. 
If the table reaches the maximum, additional START 
messages are ignored. 


timeout 


minutes 


The amount of time before a session table entry 
assumes a STOP message has been sent. The default is 
120 minutes; the range is from 0 to 65535 minutes. Zero 
indicates no timeout. 
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2. (Optional) To view the session-monitor configuration, you can either use the 

session-monitor view command or the config show session-monitor command. 

SGOS# (config) show session-monitor 

General : 

Status: enabled 

Entry timeout: 120 minutes 

Maximum entries: 500000 

Cluster support: enabled 

Cluster port: 55555 

Cluster group address: 10.9.17.159 

Synchronization delay: 0 

Synchronization grace period: 30 

Accounting protocol: radius 

Radius accounting: 

Listen ports: 

Accounting: 1813 
Responses : Enabled 
Authentication: Enabled 
Shared secret: ************ 

Creating the CPL 

Be aware that the examples below are just part of a comprehensive authentication policy. 
By themselves, they are not adequate. 



Note: Refer to Volume 10: Content Policy Language Gidde for details about CPL and how 
transactions trigger the evaluation of policy file layers. 



□ In this example, the SG appliance is using the session table maintained by the session 
monitor for authentication. 

<proxy> 

allow authenticate (session) 

where session is a policy substitution realm that uses $ ( session . username) in 
building the username. (For information on creating a Policy Substitution realm, refer 
to Volume 4: Securing the Blue Coat SG Appliance.) 

Notes 

□ The session table is stored entirely in memory. The amount of memory needed is 
roughly 40MB for 500,000 users. 

□ The session table is kept in memory. If the system goes down, the contents of the 
session table are lost. However, if the system is a member of a failover cluster, the 
current contents of the session table can be obtained from another machine in the 
cluster. The only situation in which the session table is entirely lost is if all machines in 
the cluster go down at the same time. 

□ The session replication protocol replicates session information only; configuration 
information is not exchanged. That means that each SG appliance must be properly 
configured for session monitoring. 

□ The session replication protocol is not secured. The failover group should be on a 
physically secure network to communicate with each other. 
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□ The session monitor requires sufficient memory and at least lOOMb-per-second 
network links among the cluster to manage large numbers of active sessions. 

□ The username in the session table is obtained from the Calling-Station-ID attribute in 
the RADIUS accounting message and can be a maximum of 19 bytes. 
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The Blue Coat SG Client enables users to benefit from accelerated application delivery 
directly to their desktops. This allows mobile users or users in small branch offices — 
where it might not be cost-justifiable to deploy an acceleration gateway — to enjoy 
improved networked application access. 

This chapter includes the following topics: 

□ "Overview" on page 140 

□ "About ADN Features" on page 143 

□ "Configuring Client Settings" on page 146 

□ "Configuring the Client Manager" on page 151 

□ "Configuring the SG Client from the Command Line" on page 155 

□ "Making the SG Client Software Available to Users" on page 158 

□ "Using the SG Client" on page 171 

□ "Troubleshooting Tips for Administrators" on page 171 

□ "Licensing" on page 181 
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Overview 

This section discusses the concepts you need to know to implement the SG Client in your 
enterprise: 

□ "About the Terminology" on page 140 

□ "SG Client Features and Benefits" on page 141 

□ "About SG Client Deployment" on page 142 

About the Terminology 

The following figure illustrates the terminology discussed in this chapter: 



Blue Coat SG 
Concentrator and 
SG Client Manager 



Corporate 

WAN 



«8 



o 



Small Branch 
Office 

SG Client Users 




Mobile SG Client 
Users 



Data 

Center 



Figure 12-1. Sample SG Client Deployment 



The SG Client typically connects to a concentrator, which is a Blue Coat SG appliance that is 
usually located in a data center. The SG Client connection over the Internet is assumed to 
use Virtual Private Networking (VPN). 

The concentrator receives inbound Application Delivery Network (ADN) tunnels from 
the SG Client and serves as a front end for data center resources for which it provides 
acceleration services. 



To use the SG Client, you must configure SG appliances for the following roles: 
□ Concentrator 



An SG appliance, usually located in a data center, that provides access to data center 
resources, such as file servers. 

□ Client Manager 

An SG appliance that provides the SG Client software to users, and maintains the 
software and the client configuration on all clients in the ADN network. 

You configure the Client Manager as discussed in "Configuring the Client Manager" 
on page 151. 
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□ ADN manager and backup manager (not shown in the preceding figure) 

Every ADN network must have an ADN manager, which is responsible for publishing 
the routing table to SG Clients (and to other SG appliances). Although not required. 
Blue Coat recommends configuring an ADN backup manager, which takes over for the 
ADN manager in the event it becomes unavailable. 



Note: The Client Manager can be any appliance in the ADN network, including a 

concentrator, the ADN manager, or backup manager. For example, the Client 
Manager could also be the ADN manager but that is not a requirement. 



To configure an ADN manager and backup manager, see "Defining the ADN 
Manager" on page 21. 

SG Client Features and Benefits 

The following table discusses features and benefits of the SG Client: 

Table 12-1 . SG Client Features and Benefits 



Feature 


Benefit 


Common Internet File System (CIFS) 
acceleration 


The SG Client significantly enhances Wide Area 
Network (WAN) file service delivery, improving user 
productivity by implementing the following: 

• Client object caching, which enables clients to get 
previously obtained data from cache rather than 
across the WAN. 

• CIFS protocol optimization, which improves 
performance by consolidating data forwarded across 
the WAN. 


Connect from anywhere 


The SG Client enables any user to remotely connect to 
an ADN network. 


ADN optimization 


Uses gzip compression to improve bandwidth 
utilization for TCP applications. 


Centralized management and 
distribution 


Administrators use a particular SG appliance 
designated as the Client Manager to download to 
clients SG Client software and configuration updates. 


Load balancing and failover 


Enables you to efficiently use your ADN network as a 
robust infrastructure for clients. 


Client statistics 


Provides users with real-time performance data. 
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About SG Client Deployment 

The SG Client software is deployed in two basic steps: the administrator configures the 
Client Manager to install and configure the client, then the user (or administrator) installs 
the client. After installation, the client connects to an appliance in the ADN network. This 
section discusses administrator configuration tasks and client installation tasks. 

Administrator Configuration Tasks 

The administrator: 

1. Sets up an ADN manager, backup manager, and configures the ADN network. 

2. Configures an SG appliance as the Client Manager, as discussed in "Configuring the 
Client Manager" on page 151. 

The Client Manager must be licensed, as discussed in "Licensing" on page 181. 

The Client Manager is the device from which users download the SG Client software, 
software updates, and configuration updates. 

3. Sets up the SG Client configuration (such as CIFS and ADN), as discussed in 
"Configuring General Client Settings" on page 146. 

4. Provides the SG Client software to users in one of the ways discussed in this chapter. 

For more information, see "Making the SG Client Software Available to Users" on 
page 158. 

Client Installation Tasks 

The SG Client deployment process can be summarized as follows: 

1. A user obtains the SG Client software from the Client Manager or preinstalled by an 
administrator some other way. 



Note: Installation methods are discussed in "Making the SG Client Software 

Available to Users" on page 158. 



To download the SG Client software from the Client Manager, the user must go to a 
URL provided by the administrator. 

When the user connects to the Client Manager using the URL, the user runs a setup 
application (SGClientSetup . exe) that in turn downloads and starts a Microsoft 
Installer (SGClientSetup .msi). 



Note: To run SGClientSetup.exe and SGClientSetup .msi, the user must be in the 

Administrators group on the machine. 
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2. After installing the SG Client software, the user must reboot the machine. 

3. Periodically, the SG Client polls the Client Manager for changes to the SG Client 
software and configuration. 

Software and Hardware Requirements 

For information about software and hardware requirements, see the SG Client Release 
Notes. 

About ADN Features 

This section discusses the ADN features supported by the SG Client in this release: 

□ "General ADN Feature Support" on page 143 

□ "Configuring Listening Modes" on page 144 

□ "About Internet Gateways" on page 146 

General ADN Feature Support 

The SG Client supports the following ADN features: 

□ Gzip compression, which improves bandwidth utilization 

□ CIFS protocol optimization and CIFS caching on the client 

□ Load balancing and failover 

The SG Client makes two types of connections in the ADN network: the routing 
connection and the ADN tunneling connection. The routing connection obtains the 
routing table from the ADN manager or backup manager, and the tunneling connection 
transfers data to the ADN network. 

The SG Client first attempts to connect to the primary ADN manager to get routing 
information; if it is not available, the client attempts to connect to the backup ADN 
manager. If the backup ADN manager is also not available, the connection goes 
directly to its destination as a result of fail open, which is discussed in the next bullet. 

Assuming there is more than one active SG appliance in the ADN network, the SG 
Client randomly picks an appliance from the list of appliances in the routing table and 
iterates through the list until it finds an active appliance. 

Randomly choosing an appliance — assuming there is more than one — achieves 
simple load balancing. Iterating through the list of appliances achieves failover. If no 
appliance is active, the connection goes directly to its destination as a result oifail 
open, which is discussed next. 

□ Fail open, which means that if all client connections to concentrators fail for any 
reason, the client opens a connection directly to a destination, such as a CIFS server. 

Client connections that do not go through a concentrator are not accelerated and 
remain unaccelerated as long as the connection is open (that is, until the connection is 
closed by the application). 

After a concentrator becomes available, new connections are accelerated. 
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Configuring Listening Modes 

To use the SG Client in your ADN network, you must configure options for Manager 
Listening Mode and Tunnel Listening Mode as discussed in this section. 

The SG Client does not publish routes (instead, it gets routes from the ADN Manager), 
and it uses plain communications only The options you select for Manager Listening 
Mode and Tunnel Listening Mode must be compatible with the SG Client. 

This section discusses the following topics: 

□ "Manager Listening Mode" on page 144 

□ "Tunnel Listening Mode" on page 145 

□ "Secure Outbound Mode" on page 145 



Note: To select options for either Manager Listening Mode or Tunnel Listening 

Mode, you must have previously set up a device authentication profile on the SG 
appliance. For more information about device authentication profiles, see "About 
Device Authentication Profiles" on page 88. 



Manager Listening Mode 

Manager Listening Mode determines the way routes are published in the ADN network: 
using the Plain Manager Port (non-secure communication) or the Secure Manager Port 
(secure communication), or both. 

Select Manager Listening Mode options on the ADN manager and backup manager only. 
Manager Listening Mode options are not available on other SG appliances. 

For more information about setting the Plain Manager Port and the Secure Manager Port, 
see "Defining the ADN Manager" on page 21. 

As discussed in "Securing Connections" on page 34, the following options are available: 

□ Secure Only 

This option means that only SG appliances using secure connections can publish 
routes. Fiowever, because only the secure listener is active, you cannot select this 
option if you have SG Clients in your ADN network because SG Clients use only plain 
connections. 

□ Plain Read-Only 

Select this option if all SG appliances in the ADN network use SGOS version 5.1.4 or 
later — where all appliances support secure routing, and you have chosen to utilize 
secure routing on those SG appliances. 

This option means that SG appliances that use secure connections can publish routes. 
Devices that use plain communications can get routes but cannot publish routes. 



Note: Select this option only if all appliances in the ADN network run SGOS version 

5.1.4 or later. 
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□ Plain Only 

Select this option in cases where you do not secure any ADN connections between SG 
appliances. 

This option means that only SG appliances that use plain connections can publish 
routes. 

□ Both 

Select this option if you use the SG Client in your ADN network and some appliances 
in the network are not capable of using secure connections (for example, some 
appliances run SGOS version 5.1.3 or earlier). 

This option means that SG appliances that use either secure or plain connections can 
publish routes. 

Tunnel Listening Mode 

Tunnel Listening Mode determines the type of incoming tunnel communications this SG 
appliance accepts: using the Plain Tunnel Port (non-secure communications) or the Secure 
Tunnel Port (secure communications). 

Select options for Tunnel Listening Mode on every concentrator to which you expect SG 
Clients to connect. For example, select a Tunnel Listening Mode option for the 
concentrator shown in Figure 12-1 on page 140. 

For more information about the Plain Tunnel Port and the Secure Tunnel Port, see 
"Securing Connections" on page 34. 

The following options are available: 

□ Secure Only 

This option means this SG appliance accepts only secure tunneling connections. 
Because the SG Client uses only plain connections, you cannot select this option if you 
have SG Clients in your ADN network. 

□ Plain 

Select this option to enable the SG Client to connect to the appliance in cases where 
you do not secure any ADN connections between SG appliances. 

This option means this SG appliance accepts only plain tunneling connections. 

□ Both 

Select this option if you use the SG Client in your ADN network and some appliances 
in the network are not capable of accepting incoming secure tunneling connections 
(for example, some appliances run SGOS version 5.1.3 or earlier). 

This option means this SG appliance accepts both plain and secure tunneling 
connections. 

Secure Outbound Mode 

The Secure Outbound Mode options have no impact on the SG Client because these 
options determine how SG appliances communicate with each other. For a tunneling 
connection to be established between two SG appliances, the initiating appliance's secure 
outbound mode must be compatible with the tunnel listening mode of the receiving 
appliance. 
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About Internet Gateways 

The SG Client ignores Internet Gateway settings; however, if you want to route all SG 
Client traffic through a concentrator, you can configure the concentrator to publish all 
addresses, as discussed in "Managing Server Subnets and Enabling an Internet Gateway" 
on page 26. 

Configuring Client Settings 

This section discusses how to configure the settings that affect SG Client configuration. 
Available settings include: 

□ General settings — Software update interval, TCP window size, and maximum 
percentage of client disk space to allocate for object caching. See the next section. 

□ CIFS settings — Disabling CIFS or enabling CIFS with options for write-back and 
directory cache time. See "Configuring Client CIFS Settings" on page 148. 

□ ADN settings — Primary and backup ADN manager IP addresses and port, excluded 
subnets, and included or excluded ports. See "Configuring Client ADN Settings" on 
page 149. 

Configuring General Client Settings 

This section discusses how to configure the following client settings: 

□ SG Client software update interval 

□ TCP window size 

If you know the bandwidth and round-trip delay, the TCP window size you should 
use is approximately 2 * bandwidth * delay. For example, if the bandwidth of the 
link is 8 Mbits per second and the round-trip delay is 0.75 seconds: 

TCP window size = 2 * 8 Mbits/sec * 0.75 sec = 12 Mbits = 1.5 Mbytes 

The setting in this example would be 1572864 bytes. This number goes up as 
bandwidth or delay increases, and goes down as they decrease. Because the 
bandwidth and delay for SG Client users can vary. Blue Coat recommends you test SG 
Client performance in a controlled environment before deciding on a TCP window 
size value to use in production. 

□ Maximum percentage of client disk space to use for object caching 

Regions of files that are read or written by the client are placed in the cache. Object 
caching applies to both read and write file activities. 



Note: In this release, the object cache is not encrypted. 



You can set the maximum percentage of total disk space (as opposed to available disk 
space) the SG Client allocates to the object cache. The SG Client always leaves at least 
1GB of available disk space on the client machine's system root volume. 
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Following is a summary of how object caching works on the client: 

a. The SG Client starts. 

b. The user requests a cacheable object, such as a file. 

c. The SG Client allocates sufficient disk space on the system root volume to 
cache the object — up to the limit set by the administrator. 

In other words, if the client machine's system root volume has 100GB of total 
space and the administrator configures the object cache to use a maximum of 10%, 
the SG Client allocates up to 10GB for the object cache. 

However, if the maximum cache size leaves less than 1GB of available disk space, 
the cache size is further limited. Continuing this example, if the client has only 
9GB of available space, the maximum cache size is 8GB instead of 10GB. 

d. If any single object (such as a file) exceeds the maximum cache size, that 
object is not cached. 

To continue the preceding example, if the maximum size of the object cache is 
10GB, and the client requests a file that is 11GB in size, that file is not cached. 

e. If the object cache is full, objects are expired from the cache based on a 
number of criteria, such as unopened files and oldest objects first. 

To configure general client settings: 

1. Log in to the Management Console as an administrator. 

2. Select SG Client > Client Configuration. 

3. In the right pane, click the General tab. 



4. Enter the following information: 

Table 12-2. Configuring General Client Settings 



Field 


Description 


Update interval 


Enter the frequency, in minutes, for clients to check the 
Client Manager for updated SG Client software or 
configuration updates. 

The default is 120. Valid values are between 10M32000 
(that is, 300 days). 


TCP window size 


Enter the number of bytes allowed before 
acknowledgement (the value must be between 8192 and 
4194304). The default is 65536. 


Maximum percentage of disk 
space to use for object caching 


Maximum percentage of client disk space to use for 
caching objects, such as CIFS objects. Valid values are 1- 
90; the default is 10. 

Note: The cache leaves at least 1GB available space on the 
system root volume. For more information, see 
"Configuring General Client Settings" on page 146. 



5. Click Apply to commit the changes to the SG appliance. 
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Configuring Client CIFS Settings 

This section discusses how to configure the following: 

□ Enable or disable CIFS acceleration 

□ Enable or disable write-back 

□ Set the directory cache time 

To configure CIFS settings: 

1. Log in to the Management Console as an administrator. 

2. Select SG Client > Client Configuration. 

3. In the right pane, click the CIFS tab. 

4. Enter the following information: 

Table 12-3. Configuring Client Settings for CIFS 



Item 


Description 


Enable CIFS acceleration check 
box 


• Select the check box to enable CIFS acceleration for clients. 

• Clear the check box to disable CIFS acceleration. If you clear the check box, 
the other options on this tab page are unavailable. 

For more information about CIFS acceleration, see "SG Client Features and 
Benefits" on page 141. 


Write back 


Determines whether or not users can continue sending data to the appliance 
while the appliance is writing data on the back end. 

• Select Full to enable write-back, which in turn makes the local SG Client 
proxy appear to the user as a file server; in other words, the local SG Client 
proxy constantly sends approval to the client and allows the client to send 
data while the back end takes advantage of the compressed TCP connection. 

• Select None to disable write-back. Disabling write-back can introduce 
substantial latency while clients send data to the appliance and wait for 
acknowledgement before sending more data. 

One reason to set this option to None is the risk of data loss if the link from 
the branch to the core server fails. There is no way to recover queued data if 
such a link failure occurs. 


Directory cache time field 


Number of seconds for directory listings to remain in the client's cache. 



5. Click Apply to commit the changes to the SG appliance. 
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Configuring Client ADN Settings 

This section discusses how to configure the following: 

□ ADN manager settings: 

• Primary and backup ADN manager IP addresses 

• ADN manager port 

□ ADN rules settings: 

• Excluded subnets 

Adds or removes subnets from the list of subnets not included in ADN tunnels. 
Assuming SG Clients can connect to an SG appliance that can optimize traffic to 
the destination address, this is the list of IP addresses and subnets that bypass 
ADN tunneling on the way to the destination. 

• Include and exclude ports 

Includes or excludes TCP ports in ADN tunnels. Assuming SG Clients can 
connect to an SG appliance that can optimize traffic to the destination address, 
this setting determines ports accelerated (or not accelerated) for clients. You can 
use either the excluded ports list or included ports list, but not both. 

The include and exclude ports list are advanced settings that limit the traffic that 
is accelerated by the ADN network. Because the ADN manager sets options for 
both its peers in the ADN network and for SG Clients, you can use the include or 
exclude ports list to fine-tune the way SG appliances interact with the SG Client. 

For example, if you know that SG Client traffic over particular ports is not 
compressible, you can put those ports in the exclude ports list. Blue Coat strongly 
recommends you test the include/ exclude ports settings in a controlled 
environment before using them in production because improper settings can have 
an adverse impact on performance. 

Configuring Client ADN Manager Settings 

To configure client ADN Manager settings: 

1. Log in to the Management Console as an administrator. 

2. Select SG Client > Client Configuration. 

3. In the right pane, click the ADN Manager tab. 
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4. Enter the following information: 

Table 1 2-4. Configuring Client Settings for ADN Manager 



Field 


Description 


ADN Manager 


Enter the primary ADN manager's IP address. The ADN 
manager tracks and advertises the routes to the 
appliances it knows about. 

The SG Client obtains the routing table from the ADN 
manager. 


Backup Manager 


Enter the backup ADN manager's IP address. 
Configuring a backup ADN manager is optional but 
recommended. 

If the ADN manager becomes unavailable for any reason, 
the backup ADN manager takes over the task of 
advertising routes to all ADN nodes — including SG 
Clients. 


Port 


Enter the ADN manager plain listen port. 



5. Click Apply to commit the changes to the SG appliance. 



Configuring Client ADN Rules Settings 

This section discusses how to set ADN rules settings for clients, which consist of the list of 
excluded subnets, included ports, and excluded ports. 

To configure client ADN Manager settings: 

1. Log in to the Management Console as an administrator. 

2. Select SG Client > Client Configuration. 

3. In the right pane, click the ADN Rules tab. 

4. In the Excluded Subnets section, do one of the following: 

• To add excluded subnets (in other words, to cause SG Client traffic from these 
subnets to bypass the ADN tunnel), click Add. 

In the Add IP / Subnet dialog, enter the following information and click OK when 
you are done: 

• IP / Subnet Prefix field: Enter either an IP address or an IP address and subnet 
in Classless Inter-Domain Routing (CIDR) notation (for example, 

192.168.0.1/16). 

• Subnet Mask field: Use this field if you entered only an IP address in the 
preceding field (in other words, if you used CIDR notation in the preceding 
field, you do not need to enter a value in this field). 

• To remove excluded subnets, click the subnets to remove and click Remove. You 
are required to confirm the action. 

• To clear all excluded subnets (in other words, to cause SG Client traffic from all IP 
addresses and subnets to be tunneled), click Clear all. You are required to confirm 
the action. 
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5. In the Ports section, enter the following information: 
Table 12-5. Configuring Included or Excluded Ports 



Item 


Description 


Exclude 


Client traffic from specified ports is not routed through 
the ADN tunnel. All other traffic is accelerated. 

Valid values: Comma-separated list of ports and port 
ranges (no spaces, separated by a dash character). 
Example: 22, 88, 4 43, 9 93, 995, 1352, 1494, 167 7, 
3389, 5900-5902 


Include 


Client traffic from specified ports is routed through the 
ADN tunnel and, therefore, accelerated. All other traffic 
bypasses the tunnel and is, therefore, not accelerated. 
Valid values: Comma-separated list of ports and port 
ranges (no spaces, separated by a dash character). 

Example: 80, 139, 445, 8080-8088 



Note: The include and exclude ports lists are advanced settings that limit the traffic 
that is accelerated by the ADN network. To cause all traffic to be accelerated by the 
ADN network, click either option and delete all the ports in the list. 



6. Click Apply to commit the changes to the SG appliance. 

Configuring the Client Manager 

You must configure one SG appliance in your ADN network as the Client Manager, 
meaning it is responsible for providing the SG Client software, software updates, and 
client configuration to SG Clients. The Client Manager must be licensed as discussed in 
"Licensing" on page 181. 

Note: The Client Manager can be a different appliance than the ADN manager or the 
backup ADN manager. In other words, you can configure the ADN manager or the 
backup ADN manager as the Client Manager, but it is not required. 

Setting an Appliance as the Client Manager 

This section discusses how to configure an appliance in the ADN network as the Client 
Manager. Before configuring the Client Manager, you must first specify an ADN manager 
as discussed in "Configuring Client ADN Manager Settings" on page 149. 

To set an SG appliance as the Client Manager: 

1 . Log in to the Management Console as an administrator. 

2. Select SG Client > Client Manager. 

3. In the right pane, click the Client Manager tab. 

4. Select the Enable Client Manager check box. 
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5. Enter or edit the following information: 



Note: Before you can enable an appliance to be the Client Manager, you must 
configure the ADN manager SG Clients will use. If you enable the Client Manager 
before you configure an ADN manager for clients, the following error displays when 
you attempt to apply the change: The ADN primary manager must be set prior 
to enabling the SG Client Manager. To configure the clients' ADN manager, see 
"Configuring Client ADN Manager Settings" on page 149. 

License information displays below the check box. For more information, see 
"Licensing" on page 181. 



Table 12-6. Client Manager Section 



Item 


Description 


Host 


Specify the host from which users get the SG Client software, configuration, and updates. 
Blue Coat recommends you specify a fully qualified host name, and not an unqualified 
(short) host name or IP address. If you use a fully qualified host name and the Client 
Manager's IP address changes later, you need only to update DNS for the Client Manager's 
new address and clients can continue to download the software and updates from the 
Client Manager. 

After you set this option, provide the appropriate URL to users in an e-mail or by some 
other means so they can download the SG Client software, configuration, and updates from 
that URL. 

You have the following options: 

• Use host from initial client request: ( Recommended .) Select this option to enable 
clients to download the SG Client software, configuration, and updates from the host 
from which the clients originally obtained the software and configuration. 

This option is compatible with all methods of deploying the SG Client, including 
Windows Group Policy Object (GPO) and Microsoft Systems Management Server (SMS). 
For more information about these deployment options, see "Making the SG Client 
Software Available to Users" on page 158. 

• Use host: Select this option to download the SG Client software and configuration from 
the host name you specify. Enter a fully qualified host name or IP address only; do not 
preface it with http : / / or https : / / because downloads will fail. 

Use this option to migrate users from one Client Manager to another Client Manager. 
(Also see "Changing the Client Manager URL" on page 175.) 


Port field 


Enter the port on which the Client Manager listens for requests from clients. The default is 
8084. 


Keyring list 


Select the keyring to use when clients connect to the Client Manager. 



6. Click Apply to commit the changes to the SG appliance. 
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After you apply the changes, the Client Components section displays a summary of 
the information you selected, as follows: 

Table 12-7. Client Components Section 



Item 


Description 


Client setup 


Displays the URL from which users will download the SG Client 
setup application. The setup application (SGClientSetup . exe) 
downloads the Microsoft Installer (MSI) — named 
SGClientSetup .msi — to the client. 

If you want users to install the SG Client software from the Client 
Manager, provide this URL to them. To install the software this way, 
the user must have administrative privileges on the client machine. 

Note: If you chose Use host from client request for Host as 

discussed in Table 12-6 on page 152, the URL displays as follows: 

https : // host- from-client- request: 8084/ sgclient/ 
SGClientSetup . exe 

To download the SG Client using this URL, substitute the Client 
Manager's host name or IP address for host-from-client-request . 


Client install MSI 


Displays the URL from which SGClientSetup . exe downloads 
SGClientSetup. msi. 

To install the SG Client software on client machines silently or using 
Group Policy Objects (GPO) or the Microsoft Systems Management 
Server (SMS), use SGClientSetup .msi. 


Client configuration 


Displays the URL from which the SG Client installer downloads the 
client configuration file (SGClientConf ig . xml). 


Client configuration 


Displays the most recent date and time SGClientConf ig . xml 


last modified 


was updated on the Client Manager. 



Uploading the SG Client Software to the Client Manager 

This section discusses how to upload updated SG Client software to the Client Manager 
so it can make the latest SG Client software available to install or to update on client 
machines. 

Important: After you update the Client Manager's SG Client software, whenever users 
connect using the SG Client, they must update their SG Client software. 

To upload the SG Client software to the Client Manager: 

1. If necessary, copy SGClient.cartoa location that is accessible from the machine on 
which you are running the Management Console. 

That is, if you want to upload the SG Client software from your local file system or 
from a network share drive (as opposed to uploading it from a remote URL), you 
must copy SGClient . car to an accessible location. 

2. Log in to the Management Console as an administrator. 

3. Select SG Client > Client Manager. 

4. In the right pane, click the Client Software tab. 

On the Client Software tab page, the Current SG Client Software section displays 
information about the SG Client software this Client Manager is currently using. 
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5. From the Install SG Client software from list, select one of the following: 

• Remote URL: Upload SGClient . car from a location specified by a URL in the 
following format: 

https : II host: port/ sgclient/SGCl ient_ times tamp . car 

For example, 

http : //mysg . example . com: 8004/ sgclient/SGC lien t _ times tamp . car 

• Local file: Upload the SG Client software from a location accessible by the 
machine on which you are running the Management Console. 

6. Click Install. 

You are required to confirm the action. Remember that any software or configuration 
updates require SG Client users to download the updates the next time they connect 
to the ADN network. 

7. Follow the prompts on your screen to complete the download. 



Note: A compatibility check is performed on the SG Client version you just 

uploaded. If the upload fails, you must upgrade your SGOS version before you can 
upload the SG Client . car file. 
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Configuring the SG Client from the Command Line 

This section includes the following topics: 

□ "Configuring General Client Settings (Command Line)" on page 155 

□ "Configuring Client CIFS Settings (Command Line)" on page 155 

□ "Configuring Client ADN Manager Settings (Command Line)" on page 156 

□ "Configuring Client ADN Rules Settings (Command Line)" on page 156 

□ "Setting the Client Manager (Command Line)" on page 157 

□ "Loading the Software (Command Line)" on page 157 

Configuring General Client Settings (Command Line) 

For more information about general client settings, see "Configuring General Client 
Settings" on page 146. 

To configure general client settings: 

1. At the # (config) command prompt, enter sg-client. 

2. Configure general client settings: 

# (config sg-client) max-cache-disk-percent percentage 
# (config sg-client) software-upgrade-path url 

# (config sg-client) tcp-window-size bytes 
# (config sg-client) update-interval minutes 
# (config sg-client) view 



Configuring Client CIFS Settings (Command Line) 

For more information about CIFS client settings, see "Configuring Client CIFS Settings" 
on page 148. 



To configure client CIFS client settings: 



1 . 

2. 

3. 



At the # (config) command prompt, enter sg-client. 
At the # (config sg-client) prompt, enter cifs. 



Configure CIFS settings: 



# (config 

# (config 

# (config 

# (config 

# (config 



sg-client 

sg-client 

sg-client 

sg-client 

sg-client 



cifs) 

cifs) 

cifs) 

cifs) 

cifs) 



directory-cache-time seconds 

{disable | enable} 

exit 

write-back {full | none} 

view 



155 



Volume 5: Advanced Netzvorking 



Configuring Client ADN Manager Settings (Command Line) 

For more information about client ADN Manager settings, see "Configuring Client ADN 
Manager Settings" on page 149. 

To configure client ADN manager settings: 

1. At the # (config) command prompt, enter sg-client. 

2. At the # (config sg-client) prompt, enter adn. 

3. Configure ADN manager settings: 

# (config sg-client adn) primary-manager ip-address 
# (config sg-client adn) backup-manager ip-address 
# (config sg-client adn) manager-port plain-port 

Configuring Client ADN Rules Settings (Command Line) 

For more information about client ADN rules settings, see "Configuring Client ADN 
Rules Settings" on page 150. 

To configure client ADN rules settings: 

1. At the # (config) command prompt, enter sg-client. 

2. At the # (config sg-client) prompt, enter adn. 

3. Configure ADN rules settings: 

# (config sg-client adn) port-list { exclude-ports | include-ports } 

# (config sg-client adn) {exclude-ports | include-ports} {port-list I 
port-range } 

# (config sg-client adn) exclude-subnets 

# (config sg-client adn exclude-subnets) {add | remove} 
s ubnet_pre fix [ /prefix length] 

# (config sg-client adn exclude-subnets) clear 

# (config sg-client adn exclude-subnets) exit 

# (config sg-client adn exclude-subnets) view 

# (config sg-client adn) exit 
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Setting the Client Manager (Command Line) 

For more information about configuring the Client Manager, see "Configuring the Client 
Manager" on page 151. 

To configure the Client Manager: 

1. At the # (config) command prompt, enter sg-client. 

2. Enable this appliance as the Client Manager: 

# (config sg-client) enable 



Note: Before you can enable an appliance to be the Client Manager, you must 

configure the ADN manager SG Clients will use. If you enable the Client Manager 
before you configure an ADN manager for clients, the following error displays: The 

ADN primary manager must be set prior to enabling the SG Client 
Manager. To configure the clients' ADN manager, see "Configuring Client ADN Rules 
Settings" on page 150. 



3. Configure Client Manager settings: 

# (config sg-client) client-manager host { from-client-address I <ip- 

address | host>} 

# (config sg-client) client-manager install-port port 
# (config sg-client) client-manager keyring keyring 

Loading the Software (Command Line) 

The following commands enable you to upload an updated SGClient.car file to the Client 
Manager. 

# (config sg-client) software-upgrade-path path-to-SGClient-car 
# (config) load sg-client-sof tware 
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Making the SG Client Software Available to Users 

This section discusses how administrators can make the SG Client software available to 
users in the following ways: 

□ Interactive installations started from: 

• A command line on the user's machine 

• The Client Manager 

For more information, see "Setting Up Interactive Installations" on page 159 

□ Silent installations 

For more information, see "Setting Up Silent Installations and Uninstallations" on 
page 162 

□ Windows Group Policy Object distribution 

For more information, see "Using Group Policy Object Distribution" on page 168 

□ Windows Systems Management Server (SMS) distribution 

For more information about SMS, consult the documentation provided with your 
SMS server. 



Note: For the user to run SGClientSetup . exe or SGClientSetup .msi, the user 

must be in the Administrators group on the client machine. 



Important: Do not rename SGClientSetup .msi; doing so causes future updates to fail. 

Do not edit SGClientConfig. xml on the client machine; doing so causes unpredictable 
results in future configuration updates. 
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Setting Up Interactive Installations 

Users can install the SG Client software either by downloading SGClientSetup . exe from 
the Client Manager, or manually by running SGClientSetup .msi from a command line, 
as shown in the following table: 

Table 12-8. SG Client Installation Options 



Option 


Description 


Install from Client Manager 


Provide users the URL to SGClientSetup . exe, which displays 
on the Client Manager tab page when you select SG Client > 
Client Manager. 

SGClientSetup . exe downloads and runs 
SGClientSetup .msi on the client machine. Users see the 
installation in progress and have the option of canceling the 
installation. 

For more information about this installation method, see 
"Interactive Installations from the Client Manager" on 
page 159. 


Install from the command 
line 


To install the SG Client using SGClientSetup . msi, users must 
first download it to the client machine, then execute it from the 
command line as discussed in "Interactive Manual 
Installations" on page 161. 

Note: For a complete discussion of SGClientSetup .msi 
command-line parameters, see "Setting Up Silent 
Installations and Uninstallations" on page 162. 



Note: Users who run the SG Client setup application must be in the Administrators 

group on the client machine. 



Interactive Installations from the Client Manager 

To interactively install the SG Client software from the Client Manager, the user must be in 
the Administrators group on the client machine. 

To enable users to run SGCIientSetup.exe from the Client Manager: 

Send users an e-mail with the URL to SGClientSetup . exe on the Client Manager. 

The URL displays when you select SG Client > Client Manager and click the Client Manager 
tab. 

To install the SG Client using this method: 

1. Get the URL or location from which you access SGClientSetup . exe. 

2. Click the URL in an e-mail or enter it in your browser's address field. 

3. SGClientSetup . exe starts the setup application — SGClientSetup .msi — that installs 
the SG Client software. 
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The following dialog displays if you use Internet Explorer 6: 



File Download - Security Warning 






Do you want to run or save this file? 




Name: SGClientSetup.exe 
Type: Application, 311 KB 
From: 



Run Save 



Cancel 



While files from the Internet can be useful, this file type can 
potentially harm your computer. If you do not trust the source, do not 
run or save this software. What's the risk? 



4. Click Run. 

The following dialog displays if you use Internet Explorer 6: 




Note: The preceding dialog displays because SGClientSetup . exe is not signed. 

This is due to SGClientSetup . exe being unique to each Client Manager, which in 
turn makes signing it by a recognized certificate authority difficult. 



5. Click Run. 
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The SG Client software installation begins and while it is being downloaded, a 
progress dialog similar to the following displays: 




When the installation is complete, a dialog displays two options: 

• Click Now to reboot your machine immediately. 

• Click Later to reboot your machine at a later time. 

Select this option to save work before you reboot. 

interactive Manual Installations 

To enable users to manually install the SG Client software: 

Provide a location from which the user can download SGClientSetup.msi to the client 
machine; for example, provide the user the URL to the Client Manager. 

Important: Do not rename SGClientSetup.msi; doing so causes future updates to fail. 

Do not edit SGClientConfig. xml on the client machine; doing so causes unpredictable 
results in future configuration updates. 

To install the SG Client using this method: 

1. Download SGClientSetup.msi to a location on the local file system. 

2. Do either of the following: 

• Click Start > Run, then enter the command shown in step 3. 

• Open a DOS command prompt window and change to the directory to which you 
downloaded SGClientSetup.msi 
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3. Enter the following command: 

pa th\ SGClientSetup .msi BCS I_UPDATEURL=url -to-config. xml 

where path is the absolute file system path to SGClientSetup . msi (if necessary), url - 
to-config . xml is the URL to SGClientConf ig . xml on the Client Manager. 

This URL displays when you select SG Client > Client Manager and click the Client 
Manager tab as discussed in "Configuring the Client Manager" on page 151. 

For example, 

SGClientSetup . msi BCSI_UPDATEURL=http : / /mysg . example . com : 8 08 4/ 
sgclient/ SGClientConf ig . xml 



Note: Other command-line parameters are available. For a complete list, see 

"Setting Up Silent Installations and Uninstallations" on page 162. 

4. The installation proceeds as discussed in steps 12-14 and 5 in "Interactive Installations 
from the Client Manager" on page 159. 

Setting Up Silent Installations and Uninstallations 

This section discusses how to silently install or uninstall the SG Client. 

See one of the following sections: 

□ "Parameters for Silent Installations" on page 163 

□ "Command for Silent Uninstallations" on page 165 

□ "Example Installations and Uninstallations" on page 165 

Important: Do not rename SGClientSetup .msi; doing so causes future updates to fail. 

Do not edit SGClientConfig. xml on the client machine; doing so causes unpredictable 
results in future configuration updates. 



For information about distributing the SG Client software using Group Object Policy, skip 
this section and see "Using Group Policy Object Distribution" on page 168. 
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Parameters for Silent Installations 

The following table shows command-line parameters to use with SGClientSetup .msi for 
silent installations. For examples, see "Example Installations and Uninstallations" on page 
165. 

Silent Installation Usage 

SGClientSetup. msi [/qr|/qn] BCSI_UPDATEURL=url REINSTALL=ALL 
RE INS TALLMO DE= vamu S [AUTOUPDATEDISABLED=0 | 1 ] 

[AUTOUPDATEPROHIBITED=0 | 1] [ FORCEREBOOT= { yes | no } I {y|n}] 

[REBOOTTIME=secs] [/l*v log file] 

Silent Installation Parameters 

The following table shows the meanings of the parameters that can be used for silent 
installations; for examples, see "Example Installations and Uninstallations" on page 165: 

Table 12-9. Parameters for Silent SG Client Installations 



Parameter 


Argument 


Description 


/ qr 1 /qn 




/qr (interactive, default) enables the user to see and interact 
with the installer and to cancel the installation. 

/qn (totally silent) prevents the user from seeing or 
interacting with the installer and from canceling the 
installation. 

Note: Because this is an msiexec command, other options 
are available. Enter msiexec at a command prompt for 
more information about other options. 


BCSIJJPDATEURL 


url 


URL to SGClientConf ig . xml on the Client Manager, 
which you can find as discussed in "Configuring the 
Client Manager" on page 151, entered in the following 
format: 

https : / /client-manager-host: client-manager- 
port/ sgclient/SGClientConfig. xml 


REINSTALL 


ALL 


Installs all SG Client components, whether they are already 
installed or not. 

ALL is the only supported parameter value in this release. 


REINSTALLMODE 


vamus 


Blue Coat recommends using vamus as the parameter value. 
Because this is an msiexec command, other options are 
available. For more information, see the description of this 
parameter at: http : / /msdn2 .microsoft . com/en-us/ 
library/aa371182.aspx 
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Table 12-9. Parameters for Silent SG Client Installations (Continued) 



Parameter 


Argument 


Description 


AUTOUPDATEDISABLED 


0 1 1 


0 (default) means the SG Client automatically implements 
software and configuration updates at the frequency the 
administrator specified for software update interval in 
"Configuring General Client Settings" on page 146. 

1 means the SG Client checks for software and configuration 
updates and does the following: 

• Implements configuration updates when they are 
available. 

• Implements software updates only if the user manually 
requests an update. 

This setting enables you to test the SG Client installation 
before deploying it in production. 

In other words, before you deploy the SG Client in your 
enterprise, you can test it in a controlled manner with a 
small number of users. Doing so keeps clients from 
requesting updates immediately after installation. 

(Users can manually update the software and configuration 
as discussed in the SG Client on-line help. After the user 
manually updates the software and configuration, the SG 
Client software checks for updates at the interval you 
specified in "Configuring General Client Settings" on 
page 146.) 


AUTOUPDATEPROHIBITED 


0|1 


0 (default) means the SG Client automatically implements 
software and configuration updates at the interval the 
administrator specified for software update interval in 
"Configuring General Client Settings" on page 146. 

1 means only the SG Client configuration can be updated 
(automatically or manually), but the SG Client software 
cannot be updated. Use this setting if you want to distribute 
software updates in some way other than the Client 
Manager. 

Note: AUT0UPDATEPR0HIBITED=1 takes precedence over 
AUT0UPDATEDISABLED=1. 


FORCEREBOOT 


yes [ no 

y 1 n 


This setting controls whether or not Now or Later buttons 
display on the post-installation reboot dialog, 
yes or y mean the dialog displays without buttons. 
(However, if REBOOTTIME=0, no dialog displays.) 
no or n (default) mean a dialog displays with two options: 
Now and Later, enabling users to either reboot immediately, 
wait for the timer to expire (see the next parameter), or wait 
until a later time of their choosing. 


REBOOTTIME 


secs 


Number of seconds after the SG Client installation 
completes before the user's machine is rebooted. A value of 
0 means there is no timer; to the user, a value of 0 has 
slightly different meanings, depending on the value of 
FORCEREBOOT. For more information, see "Example 
Installations and Uninstallations" on page 165. 

The default is 0. 



164 



Chapter 12: Configuring and Using the SG Client 



Table 12-9. Parameters for Silent SG Client Installations (Continued) 



Parameter 


Argument 


Description 


/hv 


logfile 


If you want the installation to be logged, enter the absolute 
file system path and file name of the log file. 



Command for Silent Uninstallations 

To silently uninstall the SG Client software, use the following command: 

msiexec /q /x { 4214C5ED-CCED-4360-90C0-69764F3D0854 } 

The string { 4214C5ED-CCED-4360-90C0-69764F3D0854 } identifies the SG Client 
installer's MSI product code. 



Note: 

□ If you changed the location of the CIFS cache as discussed in "Changing the Location 
of the CIFS Cache" on page 180, you must manually remove files from the new 
location after you uninstall the SG Client software. The SG Client uninstaller removes 
files only from the default CIFS cache folder. 

□ Users who have administrative privileges on their machines can also uninstall the SG 
Client using the Windows Control Panel's Add or Remove Programs application. 



Example Installations and Uninstallations 

This section shows the following examples: 

□ "Example Installations" on page 165 

□ "Example Uninstallation" on page 167 



Important: Do not rename SGClientSetup .msi; doing so causes future updates to fail. 

Do not edit SGClientConfig. xml on the client machine; doing so causes unpredictable 
results in future configuration updates. 



Example Installations 

Example 1: Automated, interactive installation with manual software updates possible: 

SGClientSetup . msi /qr BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
sgclient/SGClientConfig. xml REINSTALL=ALL REINSTALLMODE=vamus 
AUTOUPDATEDISABLED=l FORCEREBOOT=no REBOOTTIME=30 

The SG Client configuration downloads from the Client Manager at 

https : / /mysg. example . com: 8 084. The user sees the installation in progress and can 

cancel it. 

autoupdatedisabled=1 means that the SG Client does not implement software 
updates after the initial installation (it will, however, implement configuration 
updates). This setting enables you to test the SG Client software on a small scale 
without having to plan for client updates. 

(To get software updates manually and thereafter enable automatic updates, click 
Check for Updates on the Advanced tab page in the SG Client dialog as discussed in 
the SG Client on-line help.) 
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The REINSTALL and REINSTALLMODE parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot 

• Click Later in the dialog to defer rebooting until a later time 

• Click Now in the dialog to reboot immediately 

Example 2: Automated, interactive installation with no automatic software updates 
possible 

SGClientSetup . msi /qr BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
sgclient/SGClientConf ig . xml REINSTALL=ALL RE INSTALLMODE=vamu s 
AUTOUPDATEPROHIBITED=l FORCEREBOOT=no REBOOTTIME=3 0 

The SG Client configuration downloads from the Client Manager at 

https : / /mysg. example . com: 8 084. The user sees the installation in progress and can 

cancel it. 

autoupdateprohibited= 1 means the SG Client cannot check for software updates 
after the initial installation; however, it will check for and implement configuration 
updates. Use this setting if you want to distribute software updates in some way other 
than the Client Manager. 

The REINSTALL and REINSTALLMODE parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot 

• Click Later in the dialog to defer rebooting until a later time 

• Click Now in the dialog to reboot immediately 

Example 3: Automated, interactive installation 

SGClientSetup . msi /qr BCSI_UPDATEURL=https : //mysg . example . com: 8084/ 
sgclient/SGClientConf ig. xml REINSTALL=ALL RE INSTALLMODE=vamu s 
FORCEREBOOT=no REBOOTTIME=30 

The SG Client configuration downloads from the Client Manager at 
https : / /mysg. example . com: 8 084. The user sees the installation in progress and can 
cancel it. The reinstall and reinstallmode parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Wait 30 seconds for the machine to reboot 

• Click Later in the dialog to defer rebooting until a later time 

• Click Now in the dialog to reboot immediately 
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Example 4: Automated, interactive installation without a timer 

SGClientSetup . msi /qr BCSI_UPDATEURL=https : / /mysg . example . com: 8084/ 
sgclient/SGClientConfig. xml REINSTALL=ALL REINSTALLMODE=vamus 
FORCEREBOOT=no REBOOTTIME=0 

The SG Client configuration downloads from the Client Manager at 
https : / /mysg. example . com: 8 084. The user sees the installation in progress and can 
cancel it. The reinstall and reinstallmode parameters make sure that all SG Client 
components install, which is useful in cases where you are recovering from an 
incomplete or previously unsuccessful installation. 

After the installation is complete, the user has the following options: 

• Click Later in the dialog to defer rebooting until a later time 

• Click Now in the dialog to reboot immediately 

Example 5: Totally silent installation, immediate reboot 

SGClientSetup . msi /qn BCSI_UPDATEURL=https : //mysg . example . com: 8084/ 
sgclient/SGClientConfig. xml REINSTALL=ALL RE INSTALLMODE=vamu s 
FORCEREBOOT=yes REBOOT TIME=0 

The SG Client configuration downloads from the Client Manager specified at https : / 
/mysg . example . com: 8084. The user does not see the installation in progress and 
cannot cancel it. The user's machine is rebooted immediately after the installation is 
complete. The reinstall and reinstallmode parameters make sure that all SG 
Client components install, which is useful in cases where you are recovering from an 
incomplete or previously unsuccessful installation. 

Example Uninstallation 

msiexec /q /x { 4214C5ED-CCED-4360-90C0-69764F3D0854 } 

The string { 4214C5ED-CCED-4360-90C0-69764F3D0854 } identifies the SG Client 
installer's MSI product code. 
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Using Group Policy Object Distribution 

This section discusses how to distribute the SG Client software using Windows Group 
Policy Object (GPO). 

Important: Only an experienced Windows administrator should attempt to complete the 
tasks discussed in this section. 

To distribute the SG Client software using GPO: 

1 . Get an . ms i transform tool, such as the Orca database editor. 

Orca is a table-editing tool available in the Windows Installer SDK that can be used to 
edit your .msi files. You can also use similar tools available from other vendors. 



Note: Blue Coat does not recommend a particular transform tool. 



For more information about Orca, see: 

http : //support .micro so ft . com/kb/2 55 905/en-us 

The remainder of this section assumes you use Orca. Consult the documentation 
provided with the transform tool you are using for vendor-specific instructions. 

2. Open SGClientSetup .msi. 



3. Make the following changes to the Property table: 
Table 12-10. SGClientSetup Property Table Changes 



Property 


Action 


Value 


BCSI UPDATEURL 


Add row 


Required for all installations. 

URL to SGClientConf ig . xml on the Client Manager, 
entered in the following format: 

https :/ / client -manager-host: clien t- 
manager-port/sgclient/SGClientConf ig . xml 


FORCEREBOOT 


Edit 

value 


Required for all installations. 

Change the value from n to y. This value causes the 
user's machine to reboot after the SG Client is 
downloaded, which is required to use the SG Client. 


REINSTALL 


Add row 


Add this row and set it to al 1 only if you want to 
update the SG Client software and configuration using 
GPO. 

If clients get future SG Client software and 
configuration updates from the Client Manager, do not 
add this row. 

Also see the discussion of AUTOUPDATEPROHIBITED 
later in Table 12-11. 


REINSTALLMODE 


Add row 


Add this row and change it to vamus only if you want to 
update the SG Client software and configuration using 
GPO. 

If clients will get future SG Client software and 
configuration updates from the Client Manager, do not 
add this row. 

Also see the discussion of AUTOUPDATEPROHIBITED 
later in Table 12-11. 
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Table 12-10. SGClientSetup Property Table Changes 



Property 


Action 


Value 


AUTOUPDATEDISABLED 


Edit 


Change the value from 0 to 1 only if you want to update 
the SG Client software using GPO. (Configuration 
updates are obtained from the Client Manager whose 
URL is specified by the BCSI UPDATEURL parameter 
discussed earlier in this table.) 

1 means the SG Client checks for software updates and 
does the following: 

• Implements configuration updates when they are 
available. 

• Implements software updates only if the user 
manually requests an update. 

This setting enables you to test the SG Client installation 
before deploying it in production. 


AUTOUPDATEPROHIBITED 


Edit 

value 


Change the value from 0 to 1 only if you want to update 
the SG Client software using GPO. (Configuration 
updates are obtained from the Client Manager whose 
URL is specified by the BCSI UPDATEURL parameter 
discussed earlier in this table.) 

1 means only the SG Client configuration can be 
updated (automatically or manually), but the SG Client 
software cannot be updated. Use this setting if you want 
to distribute software updates in some way other than 
the Client Manager. 

Note: AUTOUPDATEPROHIBITED=l takes precedence 
Over AUTOUPDATEDISABLED=l. 

If clients will get future SG Client software updates from 
the Client Manager, leave this value at 0. 
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4. Make the following changes to the installExecuteSequence table: 
Table 12-11. SGClientSetup InstallExecuteSequence Table Changes 



Action 


Action 


Condition 


FIX REINSTALL 


Edit 

condition 


This change is required only if you used 

REINSTALL=all and REINSTALLMODE=vamus 

parameters. 

If required, replace the existing condition with the 
following: 

(NOT Installed) OR (REMOVE="ALL" ) 

This setting causes the SG Client to install and 
uninstall properly. 


FIX REINSTALLMODE 


Edit 

condition 


This change is required only if you used 

REINSTALL=all and REINS TALLMO DE =vamu S 

parameters. 

If required, replace the existing condition with the 
following: 

(NOT Installed) OR ( REMOVE =" ALL " ) 

This setting causes the SG Client to install and 
uninstall properly. 



5. Generate the transformation. 
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Using the SG Client 

After installing the SG Client, click the O icon in the status bar and, from the pop-up 
menu, click Help. The SG Client on-line help system discusses how to use the SG Client 
software. 

Troubleshooting Tips for Administrators 

For administrators to assist SG Client users with diagnosing errors, you need to be 
familiar with the topics discussed in this section: 

□ "Files and Folders Used by the SG Client" on page 171 

□ "SG Client Logging" on page 172 

□ "About Browser Proxies" on page 173 

□ "ADN Tunnels" on page 173 

□ "Clearing the Object Cache" on page 173 

□ "Client Manager Logging" on page 174 

□ "Advanced Troubleshooting Suggestions" on page 174 

Files and Folders Used by the SG Client 

The following table summarizes the files and folders used by the SG Client software: 
Table 12-12. SG Client Files and Folders 



File or Folder Name 


Description 


system-root-volume\Program 
Files\Blue CoatXSG Client 


Software binaries. 


SGClientSetup . log 
SGClientSetup2 . log 
SGClientUI . log 
sglog . etl 
sgdebug . etl 
sgautoupdate . log 


SG Client log files, discussed in more detail in 
"SG Client Logging" on page 172. 


%windir%\system32 \sgclient\cif s 


Object cache folder, which is the hidden folder 
in which CIFS objects are cached. For 
information about clearing the object cache, see 
"Clearing the Object Cache" on page 173. 

Note: Because the object cache is typically large 
and contains redundant data, you should 
exclude the object cache from being backed up. 
If the client machine has to be restored from 
backup, the object cache is rebuilt when the 
user performs an action such as opening or 
copying a file on a remote file system. 
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SG Client Logging 



The SG Client maintains the following logs in the user's %TMP% folder: 
Table 12-13. SG Client Log Files 



File Name 


Description 


SGClientSetup . log 


SGClientSetup . exe log; displays errors related to 
downloading SGClientConfig. xml or running 
SGClientSetup. exe. 


SGClientSetup2 . log 


SGClientSetup. msi log; displays errors related to 
installing the SG Client software. 



The SG Client maintains the following logs in the user's 
%windir % \system3 2 \sgclient\ support folder: 

Table 12-14. SG Client Log Files 



File Name 


Description 


sglog . etl 


SG Client application log. This file can reach a maximum of 
20MB in size, after which the oldest log entries are deleted as 
new entries are written. 


sgdebug . etl 


SG Client trace log. This file can reach a maximum of 20MB in 
size, after which the oldest log entries are deleted as new 
entries are written. 

This log is in a compiled format that is readable only by Blue 
Coat Engineering. 



The SG Client maintains the following log in the SG Client installation folder (for 
example, C : \Program FilesXBlue CoatXSG Client): 

Table 12-15. SG Client Log Files 



File Name 


Description 


SGClientUI . log 


Logs user interface actions. 


sgautoupdate . log 


Logs software updates but not configuration updates. 
Configuration update log messages are contained in 

sgautoupdate . log. 
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About Browser Proxies 

For users to download SG Client software and configuration updates, you might need to 
change proxy settings for SSL traffic. If you do not use a proxy for SSL traffic, you can skip 
this section. 

The following options are available: 

□ If users can connect directly to the Client Manager, change the browser 's proxy 
settings to exclude the Client Manager from being proxied. 

□ Change the proxy settings to allow connections to the Client Manager listen port (by 
default, 8084). You chose the Client Manager listen port as discussed in "Configuring 
the Client Manager" on page 151. 

This method works for all users — even those who cannot connect directly to the Client 
Manager. 



Note: The SG Client uses the Internet Explorer proxy settings to download software 

and configuration updates, so make sure you change Internet Explorer's proxy 
settings. 



ADN Tunnels 

On the General tab page of the SG Client dialog, clicking View ADN Tunnels displays 
detailed information about available tunnels, including whether a tunnel is idle or 
bypassed. 

An Idle tunnel is one that is not currently being used but for which connection information 
is preserved to decrease the amount of time required to use that connection later, if 
necessary. 

A Bypassed tunnel indicates an error with the connection to the indicated SG appliance. 

Clearing the Object Cache 

To free disk space on the user's system root volume, the user can clear the object cache by 
clicking Clear Cache on the SG Client dialog's General tab page. The object cache is located 
in the user's %windir%\system32\sgclient\cifs folder, which is a hidden folder. 

Clearing the cache affects the performance of file copies, listing directories, and opening 
files in different applications. Also, clearing the cache while the client is running does not 
delete files that are currently in use. 
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Client Manager Logging 

The Client Manager logs success or failure events related to users downloading the SG 
Client software and configuration. Each log should include timestamp, HTTP GET string 
(including the HTTP return code), and client machine name). 

To get Client Manager logs: 

Enter the following URL in your browser's address field: 

https : / /host -.port / sgclient/log 

where host is the fully qualified host name or IP address of the Client Manager, and 
port is the SG appliance's listen port. 

Advanced Troubleshooting Suggestions 

This section discusses advanced troubleshooting tools and procedures for administrators. 
The tasks discussed in this section should be performed only by administrators, or by 
users with assistance from administrators. 



Following is a brief discussion of each troubleshooting tool: 



Tool 


Description 


Shortcut 


For more 
information 


Change the 
Client Manager 
URL 


Enables you to connect to a Client Manager 
other than the one you initially downloaded 
the SG Client from. The typical use is for 
Blue Coat employees to run demonstrations, 
trials, and evaluations from different ADN 
networks. 


Advanced tab page, left 
Control+Shift, click 

Check for Updates 


"Changing the 
Client Manager 
URL" on 
page 175 


Data collector 


Collects diagnostic information useful to 
troubleshoot unexpected behavior and 
connectivity problems. 


About tab page, left 
Control+Shift, click Help 


"Using the SG 
Client Data 
Collector" on 
page 176 


Diagnostic and 

configuration 

utility 


Displays routing information for the ADN 
network, enables you to set SG Client 
software auto-update options, and enables 
you to create an SG Client service crash 
dump. 


About tab page, left 
Control+Shift, click 

System Info 


"Using the SG 
Client 

Diagnostics & 
Configuration 
Utility" on 
page 178 


Change the 
location of the 
object cache files 3 


Change the location of object cache files to a 
volume that has more space. By default, 
object cache files are stored on the user's 
system root volume. 


(No shortcut because it is 
a registry setting) 


"Changing the 
Location of the 
CIFS Cache" on 
page 180 



174 



Chapter 12: Configuring and Using the SG Client 



Changing the Client Manager URL 

When you download the SG Client or install it manually as discussed in the chapter on 
the SG Client in the Advanced Networking book, you are required to specify a Client 
Manager URL that is used to: 

□ Initially install the SG Client software from the Client Manager 

□ Download updates to the SG Client software 

□ Download updates to the SG Client configuration (the configuration includes the IP 
address of the ADN manager and backup manager, from which the SG Client obtains 
routing information for the ADN network) 

You can change the Client Manager URL, for example, to run trials or demonstrations on a 
different ADN network than the one for which you initially configured the SG Client. 

Note: If the SG Client was installed with either automatic software updates or automatic 
configuration updates disabled, those options are not changed when you change the 
Client Manager URL. Be aware of the following: 

□ If automatic software updates are prohibited, you cannot download SG Client 
software update unless you manually change the auto-update option as discussed in 
"Using the SG Client Diagnostics & Configuration Utility" on page 178. 

□ If automatic configuration updates are prohibited, you must manually check for 
configuration updates after you connect to the new Client Manager. 

For more information, see the discussion of the following installation options in the 
chapter on the SG Client in the Advanced Networking book: autoupdatedisabled and 
AUTOUPDATEPROHIBITED. 

To change the Client Manager URL: 

1. Install the SG Client as discussed in the chapter on the SG Client in the Advanced 
Networking book. 

2. Double-click the SG Client icon in the system tray. 

3. Click the Advanced tab. 

4. On the Advanced tab page, hold down left Control+Shift and click Check for Updates. 
The Change SG Client Configuration dialog displays. 

5. In the New Config URL field, enter the URL to the new Client Manager in the following 
format: 

https : / /host-or-ip -.port /path/ SGClientCon fig . xml 

where host-or-ip is the Client Manager's fully-qualified host name or IP address, port is the 
Client Manager's listen port, and path is the path to SGClientConfig.xml . 

In other words, enter the URL to SGClientConf ig . xml, which displays on the Client 
Manager tab page when you select SG Client > Client Manager. 

For example: 

https : / /mysg . example . com : 8 08 4 /sgclient/ SGClientCon fig. xml 
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6. Click OK. 

Messages display in the Change SG Client Manager dialog as the URL is verified, the 
SG Client service is stopped, and the service is restarted. After the service is restarted, 
configuration updates (if any) are downloaded to the SG Client. If automatic 
configuration updates are disabled, see step 7. 

If software updates are ready to download, you are notified before the updates are 
installed. If automatic software updates are disabled, the SG Client skips this step. To 
manually enable automatic updates on this machine, see "Using the SG Client 
Diagnostics & Configuration Utility" on page 178. 

When the operation is complete, the Advanced tab page displays the new Client 
Manager URL. 

7. If automatic configuration updates are disabled: 

a. Double-click the SG Client icon in the system tray. 

b. Click the Advanced tab. 

c. On the Advanced tab page, click Check for Updates. 

Configuration updates, if any, are downloaded to the SG Client. 

Using the SG Client Data Collector 

The SG Client Data Collector utility collects information that administrators or Blue Coat 
Support can use to diagnose problems with the SG Client application and network 
connectivity. The Data Collector gets following information, places it in a temporary 
directory, and optionally stores it in a .zip file: 

□ System information 

□ SG Client log files 

□ SG Client crash dumps 

□ SGClientConf ig . xml 

□ Information about running processes 

□ Network information 

□ Other information about the SG Client 

To run the SG Client Data Collector utility: 

1. Install the SG Client as discussed in the chapter on the SG Client in the Advanced 
Netzvorking book. 

2. Double-click the SG Client icon in the system tray. 

3. Click the About tab. 

4. On the About tab page, hold down left Control+Shift and click Help. 

The SG Client Data Collector dialog displays. 

5. Click Start. 

A green check mark displays next to each task as it completes successfully. At any 
time, click Stop to stop the data collection process. 
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6. When all tasks are complete, the Collection Complete dialog gives you the following 
options: 

• Click Save Data to save the data in a .zip file to a directory you select. 

• Click Open Folder to open the temporary folder that contains the collected data 
files. 

• Click Close. 

7. Send the data to Blue Coat Support. 

After you close the Collection Complete dialog, the SG Client Data Collector dialog 
displays as follows: 




8. You have the following options: 

• Click Open folder with collected data to view the files collected by the Data 
Collector. 

• Click Exit to close the SG Client Data Collector dialog. 
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Using the SG Client Diagnostics & Configuration Utility 

The Diagnostics & Configuration utility enables you to: 

□ View ADN network routing information 

□ View the list of excluded subnets and included ports defined by the Client Manager 

□ Enable or disable automatic software updates 

□ Create an SG Client service crash dump 

To run the SG Client Diagnostics & Configuration utility: 

1. Install the SG Client as discussed in the chapter on the SG Client in the Advanced 
Netzvorking book. 

2. Double-click the SG Client icon in the system tray. 

3. Click the About tab. 

4. On the About tab page, hold down left Control+Shift and click System Info. 

The Diagnostics & Configuration dialog displays similarly to the following: 
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5. You have the following options: 



Task 


Procedure 


View ADN network and 
routing information 


The SG Client Routing section at the top of the dialog box 
displays the following information: 

• Subnets: Displays routing information the SG Client 
obtained from the ADN manager. This information shows 
which locations are being accelerated. 

If a server does not appear to be accelerated (for example, if 
downloads from that server are slow), look at the routing 
table to see if the server is published as an accelerated 
destination. If not, the administrator should configure the 
concentrator to recognize the server as an accelerated 
destination. 

The routing table does not indicate whether a particular 
location is reachable, however. Look in the SG Client logs to 
determine whether the locations are reachable. 

To update routing information, click Refresh Routing 
Information. 

• Excluded subnets: Displays the list of excluded subnets 
defined by the Client Manager. 

• Included ports: Displays the list of included ports defined 
by the Client Manager. 

For more information about excluded subnets and included 
ports, see the chapter on the SG Client in the Advanced 
Networking book. 


Change automatic update 
options 


Click one of the following to determine whether or not the 
client can download updated software from the Client 
Manager: 

• Enabled: Users can download future SG Client software 
updates on this machine. 

• Disabled: Users cannot download future SG Client 
software updates on this machine. Choose this option to 
distribute software updates some other way (for example, 
using Windows Group Policy Object (GPO) distribution or 
Microsoft System Management Server (SMS) distribution). 


Create an SG Client service 
crash dump file 


In the event of problems with the SG Client application (such 
as crashes or freezes), click to create an SG Client service dump 
file named sgclientsvc . dmp file in the root directory of the 
system root volume (for example, C : \ ). 

Send the crash dump to Blue Coat Support as part of your 
service request. 



6. When you are finished, click Close 
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Changing the Location of the CIFS Cache 

This section discusses how to change the location the SG Client stores CIFS cache files. 
(The SG Client CIFS cache is also referred to as the object cache.) 

Note: The SG Client uninstaller removes files only from the default CIFS cache folder. If 
you change the location of the CIFS cache, you must manually remove files from the new 
location after you uninstall the SG Client software. 

By default, the CIFS cache is stored in the following folder on the system root volume: 

%windir%\system32\sgclient\cif s 

To optionally locate the files on a different volume (for example, a volume that has 
more available space): 

1. If the SG Client is already installed, perform the following tasks first: 

a. Double-click the SG Client icon in the system tray. 

b. In the SG Client dialog box, click the General tab. 

c. On the General tab page, click Clear Cache. 

This deletes or expires all the files in the current CIFS cache. 

d. Click Disable SG Client. 

e. Click Close. 

2. Create a registry value named CacheDirectory of type REG SZ (that is. String) in the 
following key: 

HKE Y_LO C AL_MAC H I NE \ S 0 F T WARE \ B 1 u e Coat Systems\SG Client 

3. Set the Value data of CacheDirectory to the location to store the object cache. 

Note: If the SG Client is not already installed, create the registry before you install the 
SG Client to avoid the user having to restart the SG Client service. Restarting the 
service stops ADN acceleration and CIFS protocol acceleration until an ADN tunnel 
can be re-established after the service starts. 

4. If you have not already done so, install the SG Client as discussed in the chapter on 
the SG Client in the Advanced Networking book. 

5. Reboot the client machine or restart the SG Client service for the registry key to take 
effect. 

To restart the SG Client service, right-click on its icon in the system tray. From the pop- 
up menu, click Disable SG Client. Right-click the icon again and, from the pop-up 
menu, click Enable SG Client. 

6. Optional. After the service restarts, manually remove any files remaining in the 
previous CIFS cache directory: 

%windir%\system32\sgclient\cif s 
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Licensing 

□ A new SG appliance has a 60-day trial license that permits you to use it with an 
unlimited number of clients. 

□ After the 60-day trial period, you are required to purchase a permanent license to 
continue using the SG Client. 

The license entitles you to support a certain number of clients in your enterprise; 
however, the license does not limit the number of ADN tunnels to which clients can 
have access. 

Client machines do not require a license to use the SG Client software; only the Client 
Manager appliance requires a license. 

□ You can upgrade your license to larger user counts. 

For information about applying a permanent Client Manager license, see the chapter on 
licensing in Volume 1: Getting Started. 
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The Blue Coat implementation of SOCKS includes the following: 

□ A SOCKS proxy server that supports both SOCKS v4/4a and SOCKSv5, running on 
the SG appliance. 

□ Support for forwarding through SOCKS gateways. 

To configure a SOCKS proxy server on the SG appliance, refer to Volume 2: Proxies and 
Proxy Services. To use SOCKS gateways when forwarding traffic, continue with this 
chapter. 

This chapter contains the following sections: 

□ Section A: "Configuring a SOCKS Gateway" on page 184. 

□ Section B: "Using SOCKS Gateways Directives with Installable Lists" on page 192. 
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Section A: Configuring a SOCKS Gateway 



Section A: Configuring a SOCKS Gateway 

SOCKS servers provide application level firewall protection for an enterprise. 

SOCKS gateways, like ICP and forwarding, can use installable lists for configuration. You 
can configure the installable list using directives. You can also use the Management 
Console or the CLI to create a SOCKS gateways configuration. Using the Management 
Console is the easiest method. 

To configure a SOCKS gateway: 

1. Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateways. 

2. Click New to create a new SOCKS gateway. 

SOCKS Gateways | SOCKS Gateway Groups | Global Defaults | Default Sequence Install SOCKS Gateway File 

SOCKS Gateways 

Name Host Port SOCKS Version 



test 19 10.1.2.3 1080 




3. Configure the SOCKS gateway as follows: 

a. Alias: Give the gateway a meaningful name. 



Note: SOCKS gateway aliases cannot be CPL keywords, such as no , default, 

forward, or socks_gateways . 



184 




Chapter 13: SOCKS Gateway Configuration 



Section A: Configuring a SOCKS Gateway 



b. Host: Add the IP address or the host name of the gateway where traffic is 
directed. The host name must DNS resolve. 

c. Port: The default is 1080. 

d. SOCKS version: Select the version that the SOCKS gateway can support from 
the drop-down list. Version 5 is recommended. 

e. Username (Optional, and only if you use version 5) The username of the user 
on the SOCKS gateway. The username already must exist on the gateway. If 
you have a username, you must also set the password. 

f. Set Password: The plaintext password or encrypted password of the user on 
the SOCKS gateway. The password must match the gateway's information. 

The password can be up to 64 bytes long. Passwords that include spaces must 
be within quotes. 

You can enter an encrypted password (up to 64 bytes long) either through the CLI 
or through installable list directives. 

g. In the Load Balancing and Host Affinity section, select the load balancing 
method from the drop-down list. Global default (configured on the 
Configuration > Forwarding > Global Defaults tab), sets the default for all 
SOCKS gateways on the system. You can also specify the load balancing 
method for this system: Least Connections or Round Robin, or you can disable 
load balancing by selecting None. 

h. In the Host affinity methods drop-down list, select the method you want to 
use: 

• HTTP: The default is to use the Global Defaults. Other choices are None, which 
disables host affinity. Accelerator Cookie, which places a cookie in the 
response to the client, and Client IP Address, which uses the client IP address 
to determine which upstream SOCKS gateway was last used. 

By default, SOCKS treats all incoming requests destined to port 80 as HTTP, 
allowing the usual HTTP policy to be performed on them, including ICAP 
scanning. If the SOCKS connection is being made to a server on another port, 
write policy on the SG appliance to match on the server host and port and 
specify that it is HTTP using SOCKS. 

• SSL: The default is to use the Global Defaults. Other choices are None, which 
disables host affinity. Accelerator Cookie, which places a cookie in the 
response to the client, and Client IP Address, which uses the client IP address 
to determine which group member was last used. In addition, you can select 
SSL Session ID, used in place of a cookie or IP address, which extracts the SSL 
session ID name from the connection information. 

• Other. Other applies to any traffic that is not HTTP, terminated HTTPS, or 
intercepted HTTPS. You can attempt load balancing of any of the supported 
traffic types in forwarding and this host affinity setting can be applied as well. 
For example, you could load balance a set of TCP tunnels and apply the Other 
host affinity (client IP only). 

The default is to use Global Defaults. Other choices are None, which disables 
host affinity, and Client IP Address, which uses the client IP address to 
determine which group member was last used. 

4. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 
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To create groups: 

An existing gateway can belong to none, one, or more groups as desired (it can only 
belong once to a single group, however). 

1. Select Configuration > Forwarding > SOCKS Gateways > SOCKS Gateway Groups. 

2. Click New to create a new SOCKS gateway group. 




3. The Add SOCKS Gateway Group dialog displays, showing the available host aliases. 
To create an alias group, highlight the hosts and groups you want grouped, and click 

Add. 

4. Give the new group a meaningful name. 

5. In the Load Balancing and Host Affinity section, select the load balancing method from 
the drop-down list. Global default (configured on the Configuration > Forwarding > 
SOCKS Gateways > Global Defaults tab), sets the default for all forwarding hosts on the 
system. You can also specify the load balancing method for this system: Least 
Connections, Round Robin, Domain Hash, URL Hash, or you can disable load balancing 
by selecting None. 

6. In the Host affinity methods drop-down lists, select the method you want to use. Refer 
to the previous procedure for details on methods. You are selecting between the 
resolved IP addresses of all of the hosts in the group, not the resolved IP addresses of 
an individual host. 
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• HTTP: The default is to use the Global Defaults. Other choices are None, which 
disables host affinity. Accelerator Cookie, which places a cookie in the response to 
the client, and Client IP Address, which uses the client IP address to determine 
which group member was last used. 

• SSL: The default is to use the Global Defaults. Other choices are None, which 
disables host affinity. Accelerator Cookie, which places a cookie in the response to 
the client, and Client IP Address, which uses the client IP address to determine 
which group member was last used. In addition, you can select SSL Session ID, 
used in place of a cookie or IP address, which extracts the SSL session ID name 
from the connection information. 

• Other. Other applies to any traffic that is not HTTP, terminated HTTPS, or 
intercepted HTTPS. You can attempt load balancing of any of the supported 
traffic types in forwarding and this host affinity setting can be applied as well. For 
example, you could load balance a set of TCP tunnels and apply the Other host 
affinity (client IP only). 

The default is to use Global Defaults. Other choices are None, which disables host 
affinity, and Client IP Address, which uses the client IP address to determine 
which group member was last used. 

7. Click OK. 

8. Click Apply to commit the changes to the SG appliance. 

Configuring Global SOCKS Defaults 

The global defaults apply to all SOCKS gateways hosts and groups unless the settings are 

specifically overwritten during host or group configuration. 

To configure global defaults: 

1. Select Configuration > Forwarding > SOCKS Gateways > Global Defaults. 




Determine how you want connections to behave if the health checks fail: Connect 
Directly (fail open) or Deny the request (fail closed). Note that failing open is an 
insecure option. The default is to fail closed. This option can be overridden by policy. 



if it exists. 
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3. Configure Global Load Balancing and Host Affinity Settings 

a. Load Balancing methods: 

• SOCKS hosts: Specify the load balancing method for all forwarding hosts 
unless their configuration specifically overwrites the global settings. You can 
choose Least Connections or Round Robin, or you can disable load balancing 
by selecting None. Round Robin is specified by default. 

• SOCKS groups: Specify the load balancing method for all forwarding groups 
unless their configuration specifically overwrites the global settings. You can 
choose to hash the domain or the full URL. You can also choose Least 
Connections, Round Robin, Domain Hash, URL Hash, and you can disable load 
balancing by selecting None. Round Robin is specified by default. 

b. Configure Global Host Affinity methods: 

• HTTP: The default is to use None, which disables host affinity. Other choices 
are Accelerator Cookie, which places a cookie in the response to the client, and 
Client IP Address, which uses the client IP address to determine which group 
member was last used. 

• SSL: The default is to use None, which disables host affinity. Other choices are 
Accelerator Cookie, which places a cookie in the response to the client, and 
Client IP Address, which uses the client IP address to determine which group 
member was last used, and SSL Session ID, used in place of a cookie or IP 
address, which extracts the SSL session ID name from the connection 
information. 

• Other: Other applies to any traffic that is not HTTP, terminated HTTPS, or 
intercepted HTTPS. You can attempt load balancing of any of the supported 
traffic types in forwarding and this host affinity setting can be applied as well. 
For example, you could load balance a set of TCP tunnels and apply the Other 
host affinity (client IP only). 

The default is to use None, which disables host affinity. You can also choose 
Client IP Address, which uses the client IP address to determine which group 
member was last used. 

c. Host Affinity Timeout: This is the amount of time a user's IP address, SSL ID, 
or cookie remains valid. The default is 30 minutes, meaning that the IP 
address, SSL ID or cookie must be used once every 30 minutes to restart the 
timeout period. 

4. Click Apply to commit the changes to the SG appliance. 

Configuring the Default Sequence 

The default sequence defines what SOCKS gateways to use when no policy is present to 
specify something different. The system uses the first host or group in the sequence that is 
healthy, just as it does when a sequence is specified through policy. Only one default 
sequence is allowed. All members must be pre-existing hosts, and no member can be in 
the group more than once. 
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A default failover sequence allow healthy hosts to take over for an unhealthy host (one 
that is failing its DNS Resolution or its health check). The sequence specifies the order of 
failover, with the second host taking over for the first host, the third taking over for the 
second, and so on. 

If all hosts are unhealthy, the operation fails either open or closed, depending upon your 
settings. 

This configuration is usually created and managed through policy. If no SOCKS-gateways 
policy applies, you can create a default sequence through the CLI. This single default 
sequence consists of a single default host (or group) plus one or more hosts to use if the 
preceding ones are unhealthy. 

To create the default sequence: 



Note: Traffic is forwarded to the first member of the list until it fails, then traffic is 

sent to the second member of list until it fails or the first member becomes healthy 
again, and so on. 



1. Select Configuration > Forwarding > SOCKS Gateways > Default Sequence. 




2. The available aliases (host and group) display in the Available Aliases pane. To select 
an alias, highlight it and click Add. 



Note: Any host or group in the default sequence is considered in use by policy. As a 

result, if you try to delete a host or group while it is in the default sequence, you 
receive an error message. You must remove the host / group from the sequence first, 
then delete the host or group. 



3. You can use the Promote and Demote buttons to change the order of the hosts and 
groups in the sequence after you add them to the Selected Aliases pane. 

4. Click Apply to commit the changes to the SG appliance. 

Related CLI Syntax to Configure SOCKS Gateways 

SGOS# (config) socks-gateways 

SGOS# (config socks-gateways) create gateway gateway_alias gateway_host 
SOCKS_port [group =group-alias] [version [=4 | =5}] [user =username 
[password=password | encrypted-password =encrypted-password}] 

SGOS# (config socks-gateways) create group group_name 
SGOS# (config socks-gateways) delete all 
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SGOS# (config socks-gateways) delete gateway gateway_alias 
SGOS# (config socks-gateways) delete group group_name 
SGOS# (config socks-gateways) destroy-old-passwords 
SGOS# (config socks-gateways) edit gateway_alias 

SGOS# (config socks-gateways gateway_alias) encrypted-pas sword 
encrypted_pas sword 

SGOS# (config socks-gateways gateway_alias) host gateway_host 



SGOS# (config socks-gateways gateway_alias) host-affinity http 
{default | none | client-ip-address | accelerator-cookie} 



SGOS# (config socks-gateways gatewayalias) host-affinity ssl 
{default | none | client-ip-address | accelerator-cookie | ssl- 
session-id} 



SGOS# (config socks-gateways gateway_alias) host-affinity other 
{default | none | client-ip-address} 

SGOS# (config socks-gateways gateway_alias) load-balance method 
{default | least-connections | none | round-robin} 



SGOS# (config socks-gateways gateway_alias) no password | user 
SGOS# (config socks-gateways gateway_alias) password password 
SGOS# (config socks-gateways gateway_alias) port socks^port 
SGOS# (config socks-gateways gateway_alias) user username 
SGOS# (config socks-gateways gateway_alias) version 4 | 5 
SGOS# (config socks-gateways gateway_alias) view 
SGOS# (config socks-gateways) edit group_alias 

SGOS# (config socks-gateways group_alias) {add | remove} 
gateway_alias 

SGOS# (config socks-gateways groupalias) host-affinity http 
{default | none | client-ip-address | accelerator-cookie} 

SGOS# (config socks-gateways group_alias) host-affinity ssl {default 
I none | client- ip-address | accelerator-cookie | ssl-session-id} 
SGOS# (config socks-gateways group_alias) host-affinity other 
{default | none | client-ip-address} 



SGOS# (config socks-gateways group_alias ) load-balance method 
{default | domain-hash | least-connections | none | round- robin | 
url-hash} 



SGOS# (config socks-gateways group_alias) view 
SGOS# (config socks-gateways) exit 

SGOS# (config socks-gateways) failure-mode {open | closed} 

SGOS# (config socks-gateways) host-affinity http {default | none | 
client- ip-address | accelerator-cookie} gateway_or_group_alias 
-or- 

SGOS# (config socks-gateways) host-affinity ssl {default | none | 
client- ip-address | accelerator-cookie | ssl-session-id} 

gateway_or_group_alias 

-or- 

SGOS# (config socks-gateways) host-affinity other {default | client- ip- 
address | none} gateway_or_group_alias 

SGOS# (config socks-gateways) load-balance gateway {default | none | 
round-robin | least-connections} gateway_alias 

SGOS# (config socks-gateways) load-balance group {default | none | 
domain-hash | url-hash | round- robin | least-connections} group_alias 
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SGOS# (config socks-gateways) no path 
SGOS# (config socks-gateways) path url 

SGOS# (config socks-gateways) sequence {add | demote | promote | 
remove} gateway-alias 

SGOS# (config socks-gateways) sequence clear 
SGOS# (config socks-gateways) view 



Statistics 

SOCKS gateways statistics are available through the Statistics > Advanced > SOCKS 
Gateways menu item. 



191 



Volume 5: Advanced Netzvorking 



Section B: Using SOCKS Gateways Directives with Installable Lists 



Section B: Using SOCKS Gateways Directives with Installable Lists 

To configure a SOCKS gateway, you can use the Management Console (easiest), the CLI, 
or you can create an installable list and load it on the SG appliance. To use the 
Management Console, see Section A: "Configuring a SOCKS Gateway" on page 184. For 
information on installing the file itself, see "Creating a SOCKS Gateway Installable List" 
on page 196. 

The SOCKS gateways configuration includes SOCKS directives that: 

□ Names the SOCKS gateways, version, and port number 

□ Creates the SOCKS gateways groups 

□ Provide load balancing and host affinity 

□ Specifies the username 

□ Specifies the password 

Available directives are described in the table below. 



Table 13-1. SOCKS Directives 



Directive 


Meaning 


gateway 


Specifies the gateway alias and name, SOCKS port, version supported, 
usernames and password. 


group 


Creates a forwarding group directive and identifies member of the 
group. 


host affinity 


Directs multiple connections by a single user to the same group 
member. 


load balance 


Manages the load among SOCKS gateways in a group, or among 
multiple IP addresses of a gateway. 


sequence 
alias list 


Adds a space-separated list of one or more SOCKS gateways and group 
aliases. (The default sequence is the default forwarding rule, used for 
all requests lacking policy instructions 


socks fail 


In case connections cannot be made, specifies whether to abort the 
connection attempt or to connect to the origin content server. 



Syntax for the SOCKS directives are: 

gateway gateway_alias gateway_name SOCKS_port [group =group_alias] 
[version={4 | 5}] [user=username] [password ^password] [encrypted- 
pas sword =encrypted_pas sword] 
group =group_alias [ gateway_alias_list ] 

host_af finity http [none | client-ip-address I accelerator-cookie} 
[ gateway_or_group_alias ] 

host_af finity ssl [none | client-ip-address I accelerator-cookie | 
ssl-session-id} [ gateway_or_group_alias ] 
host_af finity other [none I client-ip-address} 

[ gateway_or_group_alias ] 
host_af finity timeout minutes 
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load_balance group {none | domain-hash | ur 1-hash | round-robin | 
least-connections} [ group_alias ] 

load^balance gateway {none I round-robin | least-connections} 
[gateway_alias] 

sequence alias_list 
socks_fail {open | closed} 

For more information on SOCKS gateway directives, continue with the next section. For 
information on: 

□ group directives, continue with "Creating SOCKS Gateways Groups Using Directives" 
on page 194 

□ load balance directives, continue with "Configuring Load Balancing Directives" on 
page 194 

□ host affinity directives, continue with "Configuring Flost Affinity Directives" on 
page 195 

□ socks fail directives, continue with "Setting Fail Open/ Closed" on page 194 

□ sequence directives, continue with "Creating a Default Sequence" on page 196 

Configuring SOCKS Gateways Using Directives 

SOCKS gateways can be configured using the gateways suboptions in the table below. 



Table 13-2. SOCKS Gateways Syntax 



Command 


Suboptions 


Description 


gateway 




Configures the SOCKS gateway. 




gateway alias 


A meaningful name that is used for policy rules. 




gateway name 


The IP address or name of the gateway where traffic 
is directed. The gateway name must DNS resolve. 




SOCKS_port 


The port number of the SOCKS gateway. 




version={4 | 5} 


The version that the SOCKS gateway can support. 




user= username 


(Optional, if you use v5) The username of the user. It 
already must exist on the gateway. 




password ^password 


(Optional, if you use v5) The password of the user on 
the SOCKS gateway. It must match the gateway's 
information. 




encrypted- 
password ^encrypted 
password 


(Optional, if you use v5) The encrypted password of 
the user on the SOCKS gateway. It must match the 
gateway's information. 



Example 

gateway Sec_Appl 10.25.36.47 1022 version=5 user ^username 
password ^password 
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Creating SOCKS Gateways Groups Using Directives 

The SOCKS gateway groups directive has the following syntax: 

group group__name gateway_alias_l gateway_alias_2 . . . 

where group_name is the name of the group, and gateway_alias_l, gateway_alias_2, 

and so forth are the gateways you are assigning to the SOCKS gateways group. 

Setting Special Parameters 

After you configure the SOCKS gateways and groups, you might need to set other special 
parameters to fine tune gateways. You can configure the following settings: 

□ "Setting Fail Open/ Closed" 

□ "Configuring Load Balancing Directives" on page 194 

□ "Configuring Host Affinity Directives" on page 195 

Setting Fail Open/Closed 

Using directives, you can determine if the SOCKS gateways fails open or closed or if an 
operation does not succeed. 

The syntax is: 

socks_fail {open | closed} 

where the value determines whether the SOCKS gateways should fail open or fail 
closed if an operation does not succeed. Fail open is a security risk, and fail closed is 
the default if no setting is specified. This setting can be overridden by policy, using the 

SOCKS_gateway . fail^open (yes | no) property. 

Examples 

socks_fail open 

Configuring Load Balancing Directives 

Load balancing shares the load among a set of IP addresses, whether a group or a gateway 
with multiple IP addresses. 

The syntax is: 

load_balance group {none | domain-hash | ur 1-hash | round-robin | 
least-connections} [group_alias] 

load_balance gateway {none | round- robin | least-connections} 
[gateway_alias] 



Table 13-3. Load Balancing Directives 



Command 


Suboptions 


Description 


load balance 
group 


{none | domain-hash | url- 
hash | round-robin | 
least-connections } 

[ group alias] 


If you use group for load balancing, 
you can set the suboption to none or 
choose another method. If you do not 
specify a group, the settings apply as the 
default for all groups. 
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Table 13-3. Load Balancing Directives 



Command 


Suboptions 


Description 


load balance 
gateway 


{none | round-robin | 
least-connections } 

[ gateway alias] 


If you use gateway for load balancing, 
you can set the suboption to none or 
choose another method. If you do not 
specify a gateway, the settings apply as 
the default for all gateways. 



Example 

load_balance gateway least_connections 

Configuring Host Affinity Directives 

Host affinity is the attempt to direct multiple connections by a single user to the same 
group member. 

The syntax is: 

host_af finity http {none | client-ip-address I accelerator-cookie} 
[gateway_or_group_alias] 

host_af finity ssl {none | client-ip-address | accelerator-cookie | 
ssl-session-id} [ gateway__or_group_alias] 
host_af finity other {none | client-ip-address} 

[ gateway_or_group_alias ] 

host_af finity timeout minutes 



Table 13-4. Commands to Configure Host Affinity Directives 



Command 


Suboption 


Description 


host affinity 
http 


{accelerator-cookie | 
client-ip-address | none} 
[gateway or group alias] 


Determines which HTTP host-affinity 
method to use (accelerator cookie 
or client-ip-address), or you can 
specify none. If you do not specify a 
gateway or group, the settings apply as 
the default for all gateways or groups. 


host affinity 
ssl 


{accelerator-cookie I 
client-ip-address | none 
I ssl-session-id} 

[ gateway or group alias] 


Determines which SSL host-affinity 
method to use (accelerator cookie, 
client-ip-address, or ssl- 
session-id), or you can specify none. 
If you do not specify a gateway or 
group, the settings apply as the default 
for all gateways or groups. 


host affinity 
other 


other {none | client-ip- 
address } 

[gateway or group alias] 


Determines whether TCP tunnel and 
Telnet is used. Determines whether to 
use the client-ip-address host- 
affinity method or specify none. If you 
do not specify a gateway or group, the 
settings apply as the default for all 
gateways or groups. 


host affinity 
timeout 


minutes 


Determines how long a user's IP 
address, SSL ID, or cookie remains valid 
when idle 
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Example 

host_af finity ssl accelerator-cookie 10.25.36.48 
host_af finity timeout 5 

Creating a Default Sequence 

The default sequence is the default SOCKS gateways rule, used for all requests lacking 
policy instructions. Failover is supported if the sequence (only one is allowed) has more 
than one member. 



Note: Creating the default sequence through the CLI is a legacy feature. You can set up 
sequences by using policy alone. The default sequence (if present) is applied only if no 
applicable command is in policy. 

For information on using VPM, refer to Volume 6: VPM and Advanced Policy ; for 
information on using CPL, refer to Volume 10: Content Policy Language Guide. 



A default failover sequence works by allowing healthy SOCKS gateways to take over for 
an unhealthy gateway (one that is failing its DNS resolution or its health check). The 
sequence specifies the order of failover, with the second gateway taking over for the first 
gateway, the third taking over for the second, and so on). 

If all gateways are unhealthy, the operation fails either open or closed, depending upon 
your settings. 

This configuration is generally created and managed through policy. If no forwarding 
policy applies, you can create a default sequence through the CLI. This single default 
sequence consists of a single default gateway (or group) plus one or more gateways to use 
if the preceding ones are unhealthy. 

The syntax is: 

sequence alias_list 

where alias_list is a space-separated list of one or more SOCKS gateways and 
group aliases. 

Example 

sequence gateway_alias 

Creating a SOCKS Gateway Installable List 

You can create and install the SOCKS gateway installable list with the following methods: 

□ Use the Text Editor, which allows you to enter directives (or copy and paste the 
contents of an already-created file) directly onto the SG appliance. 

□ Create a local file on your local system; the SG appliance can browse to the file and 
install it. 

□ Use a remote URL, where you place an already-created file on an FTP or FITTP server 
to be downloaded to the SG appliance. 

When the SOCKS gateway installable list is created, it overwrites any previous SOCKS 
gateway configurations on the SG appliance. The installable list remains in effect until it is 
overwritten by another installable list; it can be modified or overwritten using 
Management Console or CLI commands. 
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Note: During the time that a SOCKS gateways installable list is being compiled and 
installed, SOCKS gateways might not be available. Any transactions that come into the SG 
appliance during this time might not be forwarded properly 



Installation of SOCKS gateways installable-list configuration should be done outside peak 
traffic times. 

To create a SOCKS gateway installable list: 

1. Select Configuration > Forwarding > SOCKS Gateways > Install SOCKS Gateway File. 

2. If you use a SOCKS gateway server for the primary or alternate forwarding gateway, 
you must specify the ID for the Identification (Ident) protocol used by the SOCKS 
gateway in SOCKS server handshakes. The default is BLUECOAT SYSTEMS. 

3. From the drop-down list, select the method used to install the SOCKS gateway 
configuration; click Install. 

• Remote URL: 

Enter the fully-qualified URL, including the filename, where the configuration is 
located. To view the file before installing it, click View. Click Install. Examine the 
installation status that displays; click OK. 

• Local File: 

Click Browse to bring up the Local File Browse window. Browse for the file on the 
local system. Click Install. When the installation is complete, a results window 
opens. View the results, close the window, click Close. 

• Text Editor: 

The current configuration is displayed in installable list format. You can 
customize it or delete it and create your own. Click Install. When the installation is 
complete, a results window opens. View the results, close the window, click Close. 

4. Click Apply to commit the changes to the SG appliance. 

Related CLI Syntax to specify the SOCKS Gateway Machine ID 

SGOS# (config) socks-machine-id machine_ID 
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Blue Coat health checks allow you to determine the availability of external networking 
devices. 

This chapter includes the following sections: 

□ Section A: "Overview" on page 200 

□ Section B: "About Blue Coat Health Components" on page 202 

□ Section C: "Configuring Global Defaults" on page 207 

□ Section D: "Forwarding Host and SOCKS Gateways Health Checks" on page 214 

□ Section E: "Editing External Services" on page 218 

□ Section F: "Managing User-Defined Health Checks” on page 221 

□ Section G: "Statistics" on page 227 

□ Section H: "Using Policy" on page 229 

□ Section I: "Related CLI Syntax to Configure Health Checks" on page 230 
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Section A: Overview 

Health checks are tests run on external resources, such as forwarding hosts, SOCKS 
gateways, and ICAP and Websense off-box services, to determine status. You can use 
health checks in conjunction with various failover mechanisms to handle a variety of 
failure scenarios. For example, you can use health checks with forwarding rules to 
redirect traffic from one server or proxy to another. 

If the health check for an individual host fails, the SG appliance can select a healthy host 
ahead of time or report the failure quickly. 

Health checks test for: 

□ Network connectivity 

□ Target responsiveness 

□ Basic functionality of the upstream system or service 
Health checks fall into three broad categories: 

□ Determining if the IP address can be reached. Health check types that fall into this 
category are: 

• Forwarding hosts 

• SOCKS gateways 

• Dynamic Real-Time Rating (DRTR) service 

□ Determining if a service is responsive. Health check types that fall into this category 
are: 

• ICAP services 

• Websense off -box services 

□ Determining if a group is healthy. Group tests are compilations of individual health 
checks, and the health of the group is determined by the status of the group members. 
Health check types that fall into this category are: 

• Forwarding groups 

• SOCKS gateway groups 

• ICAP service groups 

• Websense off -box service groups 



Note: The health check module has been reorganized. For specific information 

about the differences between health checks for previous versions and SGOS 5.2, refer 
to the Blue Coat SGOS 5.x Upgrade Guide. 



Health checks always have status. The status of any health check can be referenced in 
policy as a condition. For more information about using health checks in policy, see 
Section H: "Using Policy” on page 229. 
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Note: You can run an immediate health check from the Configuration > Health 

Checks > General > Health Checks tab by selecting the health check and clicking 
Perform health check. You can also view the health check state on the Statistics > 
Health Check tab, but you cannot change settings in Statistics. 



A number of health checks are automatically generated, based on: 

□ Forwarding configuration 

□ SOCKS gateways configuration 

□ ICAP configuration 

□ Websense off -box configurations 

□ Whether DRTR is enabled 

You also can create user-defined health checks, including a composite health check that 
compiles the results of multiple other health check tests. 

Background DNS Resolution 

Background testing of the DNS resolutions is done on all resolvable hostnames used in the 
health check system, including forwarding and SOCKS gateways. That way, the list of IP 
addresses associated with a hostname stays current. The DNS system is checked 
whenever the time-to-live (TTL) value of the DNS entry expires. 



Note: If a hostname consists of a dotted IP address, no DNS resolution is done. 



When a host is resolved by DNS to multiple IP addresses, health checks keep those 
addresses current through background updates, the timing of which you can configure on 
the Configuration > Health Checks > Background DNS tab. After the test or tests are 
conducted for each IP address, the results are combined. If the result for any of the 
resolved IP addresses is healthy, then the host is considered healthy because a healthy 
connection to that target can be made. 



Querying Health Checks 

A network device can query the state of any health check, automatically generated or 
user-defined, as long as you know the name of the health check to use as part of the URL. 
The URL is https://SG_appHnnce/henlth_check//test?henlth_check_nnme, where SG _appliance is 
the IP address of the system. 

If the health check is: 

□ Not found, a 400 (bad request) HTML response is sent 

□ Healthy, a 200 response is sent 

□ Unhealthy, a 404 response is sent 

In the latter two cases, a text string is sent back in the HTML response body more 
precisely describing the state of health. 
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Section B: About Blue Coat Health Components 

Health checks have two components: 

□ Health check type: The kind of device or service the specific health check tests. The 
following types are supported: 

• Forwarding host and forwarding group 

• SOCKS gateway and SOCKS gateway group 

• ICAP service and ICAP service group 

• Websense off -box service and Websense off -box service group 

• DRTR rating service 

• User-defined host and composite 

□ Health check tests: The method of determining network connectivity, target 
responsiveness, and basic functionality 

• Health checks (external targets) 

• Internet Control Message Protocol (ICMP) 

• TCP 

• SSL 

• HTTP 

• HTTPS 

• ICAP 

• Websense 

• DRTR rating service 

• Health checks (group targets) 

• Groups 

• Composite 

Note: Some health checks (forwarding hosts and SOCKS gateways) can be 

configured to report the result of some composite health check instead of their 
own test. 



Some health check types only have one matching test, while others have a selection. For 
more information about health check types and tests, see Table 14-1, "Health Check 
Tests," on page 203. 

Health Check Types 

Most health checks are automatically created and deleted when the underlying entity 
being checked is created or deleted. When a forwarding host is created, for example, a 
health check for that host is created. Later, if the forwarding host is deleted, the health 
check for it is deleted as well. User interaction is not required, except to change or 
customize the health check behavior if necessary. 
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In addition to the above health checks that are automatically generated, run, and deleted. 
Blue Coat also supports two kinds of user-defined health checks. These health checks are 
manually created, configured, and deleted. 

□ Composite health checks: A method to take the results from a set of health checks 
(automatically generated or user-defined health checks) and combine the results. 

□ Host health checks: A method to test a server, using a selection of ICMP, TCP, SSL, 
HTTP, and HTTPS tests. 



Note: Although a host health check tests an upstream server, it can also be used to 

test whether a proxy is working correctly. To test HTTP /HTTPS proxy behavior, for 
example, you can set up a host beyond the proxy, and then use forwarding rules so 
the health check passes through the proxy to the host, allowing the proxy to be tested. 



User-defined health checks allow you to test for things that Blue Coat does not test 
automatically. For example, for a forwarding host, you could do an HTTP test, an HTTPS 
test, and a TCP test of other ports. Then you can use the composite health check to 
combine the results of all the tests into one and have that reported as the forwarding host's 
health. 

All health check types are given standardized names. If a health check is created 
automatically by the Blue Coat appliance, names are based on the name of the target. For 
example: 

□ Forwarding hosts and groups have a prefix of fwd 

□ SOCKS gateways and gateway groups have a prefix of socks 

□ External services have prefixes of icap, ws, and drtr 

□ User-defined or composite health checks have a prefix of user. 

Health Check Tests 

Based on the health check type, the SG appliance periodically tests the health status, and 
thus the availability, of the host. You can configure the time interval between tests. If the 
health check test is successful, the appliance considers the host available. 

The health check tests are described in the table below. 



Table 14-1 . Health Check Tests 



Health Check Test 


Description 


Used With Health 
Check Type 


Response Times 


The minimum, maximum, and average response 
times are tracked, with their values being cleared 
whenever the health check changes state. 


All 
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Table 14-1. Health Check Tests (Continued) 



Health Check Test 


Description 


Used With Health 
Check Type 


ICMP Test (Layer 3) 


The basic connection between the Blue Coat 
appliance and the origin server is confirmed. The 
server must recognize ICMP echoing, and any 
intervening networking equipment must support 
ICMP. The Blue Coat appliance sends a ping (three 
ICMP echo requests) to the host. 

ICMP tests do not support policy for SOCKS 
gateways or forwarding. 


Forwarding hosts, 
SOCKS gateways, 
or user-defined 
hosts 


TCP Socket 
Connection Test 
(Layer 4) 


A TCP test establishes that a TCP layer connection 
can be established to a port on the host. Then the 
connection is dropped. 

TCP tests for a SOCKS gateway do not support policy 
for SOCKS gateways or forwarding. 

TCP tests for a forwarding host or a user-defined 
health check support SOCKS gateways policy but not 
forwarding policy. 


Forwarding hosts, 
SOCKS gateways, 
or user-defined 
hosts 


SSL Test 


A connection is made to a target and the full SSL 
handshake is conducted. Then, much as a TCP test, 
the connection is dropped. 

For a forwarding host, a terminating HTTPS port 
must be defined or the test fails. 

SSL tests for a forwarding host or a user- defined 
health check support SOCKS gateways policy. The 
SSL tests do not support forwarding policy. 

An SSL test executes the SSL layer in policy and 
obeys any settings that apply to server-side 
certificates, overriding any settings obtained from a 
forwarding host. 


Forwarding hosts 
or user-defined 
hosts 



204 



Chapter 14: Health Checks 



Section B: About Blue Coat Health Components 



Table 14-1. Health Check Tests (Continued) 



Health Check Test 


Description 


Used With Health 
Check Type 


HTTP/HTTPS Tests 
for Servers and 
Proxies 


HTTP /HTTPS tests execute differently depending on 
whether the upstream target is a server or a proxy. 
For a forwarding host, the server or a proxy is 
defined as part of the forwarding host configuration. 
For a user-defined health check, the target is always 
assumed to be a server. 

For a server: 

• The HTTP test sends an HTTP GET request 
containing only the URL path to an HTTP port. 

• The HTTPS test sends an HTTPS GET request 
containing only the URL path over an SSL 
connection to a terminating HTTPS port. 

If an appropriate port is not available on the target, 
the test fails. 

For a proxy: 

• The HTTP test sends an HTTP GET request 
containing the full URL to an HTTP port. 

• Since a server is required to terminate HTTPS, the 
HTTPS test sends an HTTP CONNECT request to 
the HTTP port. 

If an appropriate HTTP port is not available on the 
proxy, either test fails. 

An HTTP /HTTPS test requires a full URL for 
configuration. 

The HTTP /HTTPS tests for a forwarding host 
support SOCKS gateway policy but not forwarding 
policy. 

The HTTP /HTTPS tests for a user-defined health 
check support SOCKS gateway and forwarding 
policy. 

An HTTPS test executes the SSL layer in policy and 
obeys any settings that apply to server-side 
certificates, overriding any settings obtained from a 
forwarding host. 


Forwarding hosts 
or user-defined 
hosts. 


HTTP/HTTPS 

Authentication 


For HTTP/HTTPS tests, you can test authentication 
using a configured username and password. The 
passwords are stored securely in the registry. 


Forwarding hosts 
or user-defined 
hosts. 


HTTP/HTTPS 
Allowed Responses 


For an HTTP or HTTPS test, this is the set of HTTP 
response codes that indicate success. The default is to 
accept only a 200 response as successful. You can 
specify the sets of response codes to be considered 
successful. 


Forwarding hosts 
or user-defined 
hosts. 


External Services 
Tests 


The tests for external services are specialized tests 
devised for each particular kind of external service. 
The health check system conducts external service 
tests by sending requests to the external services 
system, which reports back a health check result. 


ICAP, Websense 
off-box, DRTR 
rating service. 
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Table 14-1. Health Check Tests (Continued) 



Health Check Test 


Description 


Used With Health 
Check Type 


Group 


Individual tests that are combined for any of the four 


Forwarding 




different available groups (forwarding, SOCKS 


groups, SOCKS 




gateways, ICAP, and Websense off -box). If any of the 


gateways groups. 




members is healthy, then the group as a whole is 


and ICAP and 




considered healthy. 


Websense off -box 




Note: Blue Coat supports a composite test, used 


external service 




only with composite (user-defined) health checks, 
that is similar to a group test except that, by 
default, all members must be healthy for the result 
to be healthy. 

These settings are configurable. 

By default, group health tests are used for two 
purposes: 

• Monitoring and notification 

• Policy 


groups. 
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Section C: Configuring Global Defaults 

In general, all health checks are initially configured to use global defaults. 



Note: The DRTR rating service is initially configured to override two of the default 

settings. The healthy interval is set to 10800 seconds (3 hours), and a failure trigger is 
set to 1. 



About Health Check Defaults 

You can change the defaults on most health checks. These defaults override global 
defaults, which are set from the Configuration > Health Checks > General > Default Settings 

tab. For information about setting or changing defaults, see Section D: "Forwarding Host 
and SOCKS Gateways Health Checks” on page 214. 

You can edit health check intervals, thresholds, and notifications for automatically 
generated health checks, but these health checks are automatically deleted if the health 
check target is deleted. 

You can configure health check intervals, thresholds, and notifications two ways: 

□ Setting the global defaults. These settings affect all health checks, unless overridden 
by explicit settings. 

□ Setting explicit values on each health check. 

The default health check values are: 

□ Ten seconds for healthy and sick intervals (an interval is from the completion of one 
health check to the start of the next health check) 

□ One for healthy and sick thresholds. A healthy threshold is the number of successful 
health checks before an entry is considered healthy; a sick threshold is the number of 
unsuccessful health checks before an entry is considered sick 

To configure intervals and thresholds, continue with "Changing Health Check Default 
Settings" on page 208. 

Enabling and Disabling Health Checks 

You can enable or disable health checks and configure them to report as healthy or 
unhealthy during the time they are disabled. If a group health check is disabled but 
reporting healthy, all members of the group are treated as healthy regardless of the status 
of the members' individual health checks. 



Note: Individual health checks for group members are still active; they can be used 

apart from the group. 



Setting a health check as disabled but reporting sick is useful to remove an upstream 
device for servicing, testing, or replacement. This setting takes the device offline after pre- 
existing traffic completes. Then the device can be safely disconnected from the network 
without altering any other configuration. 

You cannot enable or disable all health checks at once. 



207 



Volume 5: Advanced Netzvorking 



Section C: Configuring Global Defaults 



Notifications and SNMP Traps 

If you configure notifications, e-mail and event log notifications can be sent when a 
change of health check state occurs. By default, all notifications are disabled. To set 
notifications, you can change them globally, for all health checks, or explicitly, for specific 
checks. 

You can separately enable notifications of transitions to healthy and transitions to sick. A 
transition to healthy occurs as soon as the target is sufficiently healthy to be sent a request, 
even though this might not mean complete health. For example, if you have multiple IP 
addresses resolved and only one (or a few) of them work, that is healthy enough to be 
classified as healthy. The health can continue to improve. 

In the event log, state changes can be logged as either informational or severe logs. You 
can enable notifications for each resolved IP address of a target device (if applicable), in 
addition to the overall health of the device. 

An SNMP trap can also be used for notification of health check state changes. It is part of 
the Blue Coat Management Information Base (MIB) as blueCoatMgmt 7.2.1. 

To change notifications, continue with "Configuring Health Check Notifications" on page 

211 . 

Changing Health Check Default Settings 

You can set the default settings for all health checks on the Configuration > Health Checks > 
General > Default Settings tab or you can override the default settings for a health check by 
going to Configuration > Health Checks > General > Health Checks tab, selecting the health 
check, and clicking Edit. Explicit health settings override the global defaults. 

To change default settings: 

1. Select Configuration > Health Checks > General > Default Settings. 
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2. Change the settings as appropriate: 

a. Specify the healthy interval, in seconds, between health checks. The default is 
10. The healthy interval can be between 1 second and 31536000 seconds 
(about one year). 

b. Specify the healthy threshold for the number of successful health checks 
before an entry is considered healthy. Valid values can be between 1 and 
65535. The default is 1. 

c. Specify the sick interval, in seconds, between health checks to the server that 
has been determined to be sick or out of service. The default is 1 0. The sick 
interval can be between 1 second and 31536000 seconds (about 1 year). 

d. Specify the sick threshold, or the number of failed health checks before an 
entry is considered sick. Valid values can be between 1 and 65535. The default 
is 1. 

e. Specify the failure threshold for the number of failed connections to the server 
before a health check is triggered. Valid values can be between 1 and 
2147483647. By default, no value is set. 

The failures are reported back to the health check as a result of either a connection 
failure or a response error. The number of these external failures is cleared every 
time a health check is completed. If the number of failures listed meets or exceeds 
the threshold and the health check is idle and not actually executing, then the 
health of the device or service is immediately checked. 

f. Specify the maximum response time threshold, in milliseconds. The threshold 
time can be between 1 and 65535. 

3. Click OK. 

4. Click Apply to commit the changes to the SG appliance. 

To override default settings: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the test you want to modify. 

3. Click Edit. The example below uses a SOCKS gateway. 
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4. 

5. 






Edit SOCKS Gateways Health Check 

Name: socks, test 19 



Type of test: yep 



Enabled state: 0 Enabled 

O Disabled, reporting as healthy 
O Disabled, reporting as sick 

Port: 0 Use configured port 

O Use port 

r Override Defaults 



Override I the default settings 



Override Default Settings 



Override Default Settings 

Override 



0 

0 

0 

0 

□ 

□ 



Healthy interval: 

Healthy threshold: 

Sick interval: 

Sick threshold: 

J Failure trigger threshold: 

] Response time threshold: 



60 



60 



Clear all overrides 



L 



OK 



Cancel 



a 



seconds 



seconds 



milliseconds 



To substitute special values for this test, click Override the default settings. 



Select the check boxes to override. You can cancel your choices by clicking Clear all 
overrides. 

a. Specify the healthy interval, in seconds, between health checks to the server. 
The default is 10. The healthy interval is between 1 second and 31536000 
seconds (about one year). 

b. Specify the healthy threshold for the number of successful health checks 
before an entry is considered healthy. Valid values are 1-65535. The default is 

1 . 

c. Specify the sick interval, in seconds, between health checks to the server that 
has been determined to be sick or out of service. The default is 1 0. The sick 
interval is between 1 second and 31536000 seconds (about 1 year). 

d. Specify the sick threshold, or the number of failed health checks before an 
entry is considered sick. Valid values are 1-65535. The default is 1 . 
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e. Specify the failure trigger for the number of failed connections to the server 
before a health check is triggered. Valid values are between 1 and 2147483647. 

The failures are reported back to the health check as a result of either a connection 
failure or a response error. The number of these external failures is cleared every 
time a health check is completed. If the number of failures listed meets or exceeds 
the threshold, and the health check is idle and not actually executing, then the 
health of the device or service is immediately checked. 

f. Specify the maximum response time threshold, in milliseconds. The threshold 
time can be between 1 and 65535. 

6. Click OK. 

7. Click Apply to commit the changes to the SG appliance. 

Configuring Health Check Notifications 

By default, notifications of health check events and status are disabled. You can set up 
health check notifications globally, on the Configuration > Health Checks > General > 
Default Notifications tab, or explicitly by going to the Configuration > Health Checks > 
General > Health Checks tab, selecting the health check, and clicking Edit. Explicit health 
settings override the global defaults. 

To configure health check notifications globally: 

1. Select Configuration > Health Checks > General > Default Notifications. 




2. Select the check boxes to enable notifications. 

a. E-mail notification: Select the appropriate check boxes to enable the email 
notifications you require. Recipients are specified in Maintenance > Event 
Logging > Mail. 

b. Event logging: Select the appropriate check boxes to enable the event logging 
you require. Messages can be logged as either informational or severe. 

c. SNMP traps: Select the situations for which you require SNMP traps to be 
sent. 

3. Click Apply to commit the changes to the SG appliance. 
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To override health check notification default settings: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the test you want to modify. 

3. Click Edit. The example below uses a forwarding host. 

4. To change default notifications for this test, click Override the default notifications. By 
default, notifications are not sent for any health checks. 




5. Select the check boxes to override. You can cancel your choices by clicking Clear all 
overrides. 
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a. Override E-mail notification: Select the appropriate check boxes to enable the 
email notifications you required. Specify recipients in Maintenance > Event 
Logging > Mail. 

b. Event logging: Select the appropriate check boxes to enable the event logging 
you need. Messages can be logged as either informational or severe. 

c. SNMP traps: Select the situations in which you want SNMP traps to be sent. 

d. Click OK. 

e. Click OK. 

6. Click Apply to commit the changes to the SG appliance. 
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Section D: Forwarding Host and SOCKS Gateways Health Checks 

Before you can edit forwarding or SOCKS gateways health check types, you must 
configure forwarding hosts or SOCKS gateways. For information about configuring 
forwarding, see Chapter 8: "Configuring the Upstream Network Environment" on page 
101; for information about configuring SOCKS gateways, see Chapter 13: "SOCKS 
Gateway Configuration" on page 183. 

This section discusses managing automatically generated health checks. To create health 
checks using the user-defined health check type, continue with Section F: "Managing 
User-Defined Health Checks" on page 221. 

Forwarding Hosts and SOCKS Gateways Configurations 

The forwarding host health check configuration defines whether the target being tested is 
a server or a proxy, which ports are available, and provides the setting for the server 
certificate verification. 

The SOCKS gateways health check configuration defines the SOCKS port, the version (4 
or 5), and possibly a username and password. 

Forwarding Hosts Health Checks 

The default for a newly created forwarding host is a TCP health check using the first port 
defined in the forwarding host's port array (typically the HTTP port). You can change the 
port setting. The TCP test can support forwarding policy ( SOCKS gateways policy). The 
URL uses the forwarding host hostname, such as tcp://<gateway-name>:<port>/. 

SOCKS Gateways Health Checks 

The default for a newly created SOCKS gateway is a TCP health check using the SOCKS 
port in the SOCKS gateways configuration. 

Forwarding and SOCKS Gateways Groups Health Checks 

Specific tests are not done for groups. Health check test results are determined from 
examining and combining the health of the group members. 



Note: You can create groups in the Configuration > Forwarding > Forwarding Hosts 

tab or Configuration > Forwarding > SOCKS Gateways tab. 



By default, if any of the members of the group are healthy, then the group is considered 
healthy. You can specify the number of group members that must be healthy for the group 
to be considered healthy. 

Configuring Forwarding and SOCKS Gateways Health Checks 

You can edit, but not delete, the automatically generated forwarding tests and groups. You 
can create, edit, copy, and delete user-defined tests. 
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Editing Automatically Generated Tests for Forwarding and SOCKS 
Gateways 

The settings you can change on automatically generated forwarding hosts, SOCKS 
gateways, and forwarding and SOCKS gateways group tests are: 

□ Enabled state 

□ Override default notifications 

□ Type of test 

□ Settings specific to the type of test 

□ Override default settings 

□ Minimum number of healthy group members 

To edit automatically generated forwarding and SOCKS gateways tests: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the forwarding host test or SOCKS gateways test to modify 

3. Click Edit. 




4. Make the necessary changes: 

a. Select the Type of Test from the drop-down list. 

b. Select the Enabled state radio button as required. 
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c. Select the port setting you require. If you select Use Port, enter the new port 
number. 

d. To change the default settings for this test, click Override the default settings. 

• Select the check boxes to override. Cancel your choices by clicking Clear all 
overrides. For detailed information about configuring healthy and sick 
intervals and thresholds, see "Changing Health Check Default Settings" on 
page 208. 

• Click OK. 

e. To change default notifications, click Override the default notifications. By 
default, no notifications are sent for any health checks. 

• Select the check boxes to override. You can cancel your choices by clicking 
Clear all overrides. For detailed information about configuring notifications, 
see "Configuring Health Check Notifications" on page 211. 

• Click OK . 

f. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 

To edit automatically generated forwarding or SOCKS gateway group tests: 



Note: The only way to add or delete group members to the automatically generated 

health check tests is to add and remove members from the actual forwarding or 
SOCKS gateway group. The automatically generated health check is then updated. 



1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the forwarding or SOCKS gateways group health check you need to modify. 

3. Click Edit. 




4. Make the necessary changes: 

a. Select the Enabled state radio button as required. 
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b. Select the Minimum number of users that must be healthy for group to be 
healthy from the drop-down list. 

c. To create notification settings, click Override the default notifications. 

• Select the check boxes. Cancel your choices by clicking Clear all overrides. For 
detailed information about configuring notifications, see "Configuring Health 
Check Notifications" on page 211. 

• Click OK. 

d. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 
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Section E: Editing External Services 

External Services include ICAP, Websense off-box, and the DRTR rating service. While 
external service health checks are created and deleted automatically, the service itself must 
be created before health checks can be used. For more information about creating ICAP 
and Websense off-box services, refer to Volume 7: Managing Content. The DRTR rating 
service is automatically created if you use Blue Coat Web Filter (BCWF) and have the 
rating service enabled. 



Note: The names of the ICAP and Websense off -box services and service groups can 

be a maximum of 64 characters long, a change from previous releases, which allowed 
names to be a maximum of 127 characters. If a previously existing name exceeds 64 
characters, the service or service group continues to function normally but no 
corresponding health check type is created. 



The tests for each of the external services are specialized tests devised for each particular 
kind of external service. The health check system conducts external service tests by 
sending requests to the external services system, which reports back a health check result. 



Note: You can run a health check on any health check on the Configuration > Health 

Checks > General > Health Checks tab by selecting the health check and clicking 

Perform health check. 



The settings you can change on automatically generated ICAP, Websense off -box, and 
DRTR rating service tests are: 

□ Enabled state 

□ Override default settings 

□ Override default notifications 

To edit automatically generated external services tests: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the external service to modify. External services have prefix names of drtr, icap, 
and ws. 

3. Click Edit. 
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4. Make the necessary changes: 

a. Change the Enabled state radio button as required. 

b. (Websense only): If you do not want to use the default URL, select the Use 
user defined URL option and enter the test URL to use. 

c. To change default settings, click Override the default settings. 

• Select the check boxes to override. Cancel your choices by clicking Clear all 
overrides. For detailed information about configuring healthy and sick 
intervals and thresholds, see "Changing Health Check Default Settings" on 
page 208. 



Note: DRTR has settings that differ from the defaults for other external 

services: 10800 seconds (3 hours) for the interval, and 1 for the failure trigger. 



• Click OK. 

d. To change default notifications, click Override the default notifications. By 
default, no notifications are sent for any health checks. 

• Select the check boxes. Cancel your choices by clicking Clear all overrides. For 
detailed information about configuring notifications, see "Configuring Health 
Check Notifications" on page 211. 

• Click OK. 

e. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 
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To edit automatically generated Websense off-box or ICAP group tests: 



Note: The only way to add or delete group members to the automatically generated 

health check tests is to add and remove members from the ICAP or Websense off-box 
services. The automatically generated health check type is then updated. 



1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the external service group health check to modify. Groups are identified in the 
Type column. 

3. Click Edit. 




4. Make the necessary changes: 

a. Select the Enabled state radio button as required. 

b. Select the Minimum number of users that must be healthy for group to be 
healthy from the drop-down list. The default is that one member of the group 
must be healthy. 

c. To create notification settings, click Override the default notifications. 

• Select the check boxes. Cancel your choices by clicking Clear all overrides. For 
detailed information about configuring notifications, see "Configuring Health 
Check Notifications" on page 211. 

• Click OK. 

d. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 
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Section F: Managing User-Defined Health Checks 

You can manually create and manage ICMP, TCP, HTTP /HTTPS, or SSL health check tests 
for any upstream TCP/IP device. You can use these user-defined health check types to 
send notifications of health check state changes. The composite check is made up of any 
set of checks, including other composite health checks, health checks for user defined 
hosts, and any automatically generated health checks. 

Under most circumstances, you do not need to create user-defined health checks; the 
automatically generated health checks meet most needs, and you can modify the default 
sick/healthy parameters, change the default test type, or add notification settings. For 
information about configuring parameter and notification settings for automatically 
generated health check types, see Section C: "Configuring Global Defaults" on page 207. 

However, you might need tests to check for things that Blue Coat does not test 
automatically. For example, you can control traffic based on the apparent health of the 
Internet. Using user-defined health check types, you can target known Internet sites, 
accepting that so long as a certain number of the sites are healthy, then the Internet is 
considered healthy. 



Note: Frequent testing of specific Internet sites by a large number of systems can 

result in that Internet site objecting to the number of hits. 



Blue Coat supports two types of user-defined health checks: 

□ Host: This health check type is for any upstream TCP /IP device. For more 
information, continue with the next section. 

□ Composite: This health check type is meant to compile the results of any kind of 
health check. For more information, continue with "About User-Defined Composite 
Health Checks" on page 222. 

About User-Defined Host Health Checks 

You can create, configure, and delete user-defined host health checks are health checks. 

These health checks support everything an automatically generated health check contains, 

including background DNS resolution monitoring and support for multiple addresses. 

User-defined host health check tests can include: 

□ ICMP: The basic connection between the Blue Coat appliance and the origin server is 
confirmed. The server must recognize ICMP echoing, and any intervening 
networking equipment must support ICMP. 

□ TCP: Establishes that a TCP layer connection can be made to a port on the host. Then 
the connection is dropped. 

□ SSL: A connection is made to a target and the full SSL handshake is confirmed. Then 
the connection is dropped. 

□ HTTP/ HTTPS: An HTTP or HTTPS test is defined by the URL supplied. The port 
used for this test is as specified in that URL. If no port is explicitly specified in the 
URL, the port defaults to the standard Internet value of 80 or 443. 
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When configuring user-defined host health check types, keep in mind the following: 

□ User-defined host health checks are created and deleted manually. 

□ All individual user-defined tests consider the target to be a server. 

□ To conduct proxy HTTP /HTTPS tests, a proxy must be defined as a forwarding host, 
set up between the originating device and the target, and forwarding policy must 
cause the test to be directed through the proxy. 

□ For an ICMP test, a hostname is specified in the health check configuration. 

□ The TCP and SSL tests support SOCKS gateway policy, based on a URL of tcp:// 
<hostname>:<port>/ and ssl://<hostname>:<port>/, respectively, using a hostname and 
port supplied in health check configuration. 

□ An HTTP /HTTPS test requires a full URL. The port used for this test is as specified in 
that URL. If no port is explicitly specified in the URL, the port defaults to the standard 
value for these protocols of 80 or 443. The server being tested is assumed to support 
whatever port is indicated. 

Forwarding and SOCKS gateway policy is applied based on the URL. The HTTPS or 
SSL tests use all the server certificate settings in the SSL layer in policy. For a 
forwarding host, all the sever certificate settings in the SSL layer also apply, and if 
present, override the forwarding host configuration setting. 



Note: None of the above tests apply to user-defined composite health checks, which 

only consist of a set of members and a setting to combine the results. 



About User-Defined Composite Health Checks 

User-defined composite health checks can be used to collect together a set of health 
checks. 

You can define a composite health check that is made up of the results of other existing 
health checks. The forwarding host and SOCKS gateway health checks can have a test that 
references the result of some composite health check. The composite health check allows 
you to combine results of tests of one device or tests of multiple devices. 

You can also define how many member health checks must be healthy for the composite 
result to be considered healthy. By default, all members of composite tests must be healthy 
for the combination to be healthy. 

User-defined composite health checks with no members always appear unhealthy. 



Note: Automatically generated group tests and user-defined composite tests are not 
the same. 

Group tests are automatically generated; they cannot be deleted. Some editing is 
permitted, but you cannot add or remove members of the group through the health 
checks module (you must modify the forwarding or SOCKS gateways groups to 
update the automatically generated group tests). 

For a group's test, the default is for the group to be healthy if any member is healthy. 
For a composite's test, the default is for the group to be healthy if all members are 
healthy. (The default is configurable.) 
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Creating User-Defined Host and Composite Health Checks 

You can create user-defined host and composite health checks for arbitrary targets. 



Note: You cannot create user-defined health checks for external service tests, such as 

ICAP, Websense off-box, and the DRTR rating service. 



The following procedure explains how to create a user-defined host health check. To 
create a user-defined composite health check, continue with "To create a user-defined 
composite health check:" on page 224. 

To create a user-defined host health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Click New. 




3. Select the type of test to configure from the Type of test drop-down list. To configure a 
composite test, see "To create a user-defined composite health check:" on page 224. 
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The options you can select vary with the type of health check. The example above 

uses the HTTP /HTTPS options. Options for other tests are explained in this 

procedure, as well. 

a. Enter a name for the health check. 

b. Select the Enabled state radio button to the required setting. 

c. If you are configuring an SSL or TCP health check, enter the port to use. 

d. If you are configuring an ICMP, SSL, or TCP health check, enter the hostname 

of the health check's target. 

e. For HTTP/HTTPS only: 

• Enter the URL address of the target. 

• To use Basic user authentication, select the check box and enter the username 
and password of the target. 

• To use Basic proxy authentication because intermediate proxies might be 
between you and the target, select the check box and enter the username and 
password of the target. 

• To manage a list of HTTP /HTTPS response codes that are considered 
successes, enter the list in the Allowed Response Code field, separated by 
semi-colons. If one of them is received by the health check then the health 
check considers the HTTP(S) test to have been successful. 



Note: The 200 response code is added by default. The list must always have 

at least one member. 



f. To change the default settings for this test, click Override the default settings. 

• Select your override settings. Cancel your choices by clicking Clear all 
overrides. For detailed information about configuring healthy and sick 
intervals and thresholds, see "Changing Health Check Default Settings" on 
page 208. 

• Click OK. 

g. To change the default notifications for this test, click Override the default 

notifications. By default, no notifications are sent for any health checks. 

• Select the check boxes to override. You can cancel your choices by clicking 
Clear all overrides. For detailed information about configuring notifications, 
see "Configuring Health Check Notifications" on page 211 

• Click OK. 

h. Click OK. 

4. Click Apply to commit the changes to the SG appliance. 

To create a user-defined composite health check: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Click New. 
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3. Make the necessary changes: 

a. Select Composite from the Type of Test from the drop-down list. 

b. Select the Enabled state radio button as required. 

c. Select the Minimum number of members that must be healthy for the group to be 
healthy from the drop-down list. The default is All. 

d. Add the health check members to the composite test from the Available 
Aliases list by selecting the health check to add and clicking Add to move the 
alias to the Selected Alias list. 

e. To change the default notifications for this test, click Override the default 
notifications. By default, no notifications are sent for any health checks. 

• Select the check boxes to override. You can cancel your choices by clicking 
Clear all overrides. For detailed information about configuring notifications, 
see "Configuring Health Check Notifications" on page 211 

• Click OK. 

f. Click OK. 

4. Click Apply to commit the changes to the SG appliance. 
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Copying and Deleting User-Defined Health Checks 

Only user-defined health checks can be copied and deleted. Automatically generated 
health checks cannot be copied or deleted. 

□ If the source health check is user-defined host or a composite and the target alias 
name does not exist: 

• A new health check of the same kind with that alias name is created 

• The new health check has identical configuration settings to the source health 
check. 

□ If the target alias does exist and the target is of the same kind (that is, both are user- 
defined hosts or both are composite), then the complete configuration is copied from 
the source to the target. 

To copy or delete user-defined host or composite health checks: 

1. Select Configuration > Health Checks > General > Health Checks. 

2. Select the user-defined host or composite health check to copy. 

3. Click Copy. 




If the target does not match the source type, the copy operation fails and sends an 
error message. 
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Section G: Statistics 



Section G: Statistics 

You can view but not edit the health check state from the Statistics > Health Check tab. To 
manage health checks, go to the Configuration > Health Checks > General tab. 

To view the health check state: 

Select Statistics > Health Check. 



Health Check 



Name 


Active 


Status 


drtr.cerberian_drtr 


Enabled 


Unknown health 


drtr.rating_service 


Enabled 


Unknown health 


icap.icap_requestl 


Enabled 


Health check failed 


icap.icap_responsel 


Enabled 


Health check failed 


icap . icap_response_backup 1 


Enabled 


Health check failed 


icap . icap_response_backup2 


Enabled 


Health check failed 


ws.testl 


Enabled 


Health check failed 


ws.test2 


Enabled 


Health check failed 


fwd.group2 


Enabled 


Health check failed 


fwd.host2 


Enabled 


Functioning properly 


fwd.testl 


Enabled 


Health check failed 


socks. testl9 


Enabled 


Health check failed 


user, be 1 


Enabled 


Functioning properly 


user, composite 1 


Enabled 


Health check failed 


user, http 1 


Enabled 


Functioning properly 


user, https 1 


Enabled 


Health check failed 


user.icmpl 


Enabled 


Functioning properly 


user.ssll 


Enabled 


Health check failed 


user.tcpl 


Enabled 


Functioning properly 


user.test2 


Enabled 


Health check failed 


user.test3 


Enabled 


Health check failed 



Table 14-2. Status Messages for Health Checks 



Status Message 


Description 


Health State 


Unknown health 


Health has not yet been tested 
successfully. 


Healthy 


Functioning properly 


The target device or service is completely 
healthy. 


Healthy 


Functioning with errors (multiple 

IP addresses) 


One or more IP addresses have errors but 
none are down. 


Healthy 


Functioning only for some 
addresses (multiple IP addresses) 


One or more IP addresses are down but 
not all. 


Healthy 


Functioning but going down 

(single IP address) 


Failures are occurring, but the IP address 
is not yet down. 


Healthy 


Health check failed 


Device or service cannot be used. 


Sick 


DNS resolution failed 


The hostname cannot be DNS resolved. 


Sick 
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Section G: Statistics 

In addition to status messages, you can see whether the health check is enabled. Enabled 
states are: 

□ Enabled 

□ Disabled, reporting success 

□ Disabled, reporting failure 
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Section H: Using Policy 



Section H: Using Policy 

The results of a health check can be affected through forwarding, SOCKS gateway, or SSL 
certificate policy. The health check transactions execute the <forward> layer and (for SSL 
or HTTPS tests) the <ssl> layer to determine applicable policy 

This allows health check behavior to match as closely as possible that of the SSL traffic 
that the health check is monitoring. 

Health checks cannot be deleted while referenced in policy. If a health check is 
automatically deleted when its target is deleted, a reference to the health check in policy 
can block deletion not only of the health check but of its target. 

Two policy conditions exist for health checks: 

□ health_check= This condition tests whether the current transaction is a health check 
transaction. Optionally, the condition tests whether the transaction is that of a specific 
health check. 

□ is_healihy.health_check_name= This condition tests whether the specified health check 
is healthy. 

For more information about using policy, refer to Volume 6: VPM and Advanced Policy and 
Volume 10: Blue Coat SG Appliance Content Policy Language Gidde. 
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Section I: Related CLI Syntax to Configure Health Checks 



Section I: Related CLI Syntax to Configure Health Checks 

□ To enter health check mode: 

SGOS# (config) health-check 
SGOS# (config health-check) 



Note: For detailed information about using these commands, refer to Volume 11: 

Command Line Reference . 



□ The following subcommands are available: 

SGOS# (config health-check) copy source-alias target-alias 
SGOS# (config health-check) create {composite alias_name I http 
alias_name url | https alias_name url | icmp alias_name hostname I ssl 
alias_name hostname [port] | tcp alias_name hostname [port]} 

SGOS# (config health-check) default e-mail {healthy {enable | disable } | 
report-all-ips {enable | disable} | sick {enable | disable}} 

SGOS# (config health-check) default event-log {healthy {enable 
| disable} | report-all-ips {enable | disable} | sick {enable | 
disable } } 

SGOS# (config health-check) default failure- trigger {none | count} 
SGOS# (config health-check) default interval {healthy seconds | sick 
seconds} 

SGOS# (config health-check) default snmp {healthy {enable Idisable} | 
report-all-ips {enable | disable} | sick {enable | disable}} 

SGOS# (config health-check) default threshold {healthy count I 
response-time milliseconds I sick count} 

SGOS# (config health-check) delete alias^name 

SGOS# (config health-check) disable {healthy alias_name | sick 
alias_name} 

SGOS# (config health-check) edit compos ite_health_check 

(config health-check user . compos ite_health_check) subcommands 
SGOS# (config health-check) edit drtr . test_name 
(config health-check drtr . testname) subcommands 

SGOS# (config health-check) edit fwd . group_name 
(config health-check fwd. group_name) subcommands 

SGOS# (config health-check) edit fwd . host_name 
(config health-check fwd . host_name) subcommands 
SGOS# (config health-check) edit health_check_name 

(config health-check user . health_check_name) subcommands 
SGOS# (config health-check) edit i cap . test_name 
(config health-check icap . testname) subcommands 
SGOS# (config health-check) edit socks . test_name 
(config health-check socks . test_name) subcommands 

SGOS# (config health-check) edit ws . test_name 
(config health-check ws .testname) subcommands 
SGOS# (config health-check) edit ws . group_name 
(config health-check ws . groupname) subcommands 
SGOS# (config health-check) enable alias^name 
SGOS# (config health-check) exit 
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Section I: Related CLI Syntax to Configure Health Checks 



SGOS# (config health-check) perf orm-health-check alias_name 

SGOS# (config health-check) view {configuration | quick-statistics | 

statistics } 
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Section I: Related CLI Syntax to Configure Health Checks 
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Use the TCP/IP configuration options to enhance the performance and security of the 

SG appliance. Except for IP Forwarding (refer to Volume 2: Proxies and Proxy Services), 

these commands are only available through the CLI. 

□ RFC-1323: Enabling RFC-1323 support enhances the high-bandwidth and long- 
delay operation of the SG appliances over very high-speed paths, ideal for satellite 
environments. 

□ TCP NewReno: Enabling TCP NewReno support improves the fast recovery of the 
appliances. 

□ ICMP Broadcast Echo: Disabling the response to these messages can limit security 
risks and prevent an attacker from creating a distributed denial of service (DDoS) to 
legitimate traffic. 

□ ICMP Timestamp Echo: Disabling the response to these messages can prevent an 
attacker from being able to reverse engineer some details of your network 
infrastructure. 

□ TCP Window Size: Configures the amount of unacknowledged TCP data that the 
SG appliance can receive before sending an acknowledgement. 

□ PMTU Discovery: Enabling PMTU Discovery prevents packets from being unable 
to reach their destination because they are too large. 

To view the TCP/IP configuration, see "Viewing the TCP/IP Configuration" on page 

236. 

This section discusses 

□ "RFC-1323" on page 233 

□ "TCP NewReno" on page 234 

□ "ICMP Broadcast Echo Support" on page 234 

□ "ICMP Timestamp Echo Support" on page 234 

□ "TCP Window Size" on page 235 

□ "PMTU Discovery" on page 235 

□ "TCP Time Wait" on page 235 

□ "TCP Loss Recovery Mode" on page 236 

□ "Viewing the TCP /IP Configuration" on page 236 



RFC-1323 

The RFC-1323 TCP/IP option enables the SG appliance to use a set of extensions to TCP 
designed to provide efficient operation over large bandwidth-delay-product paths and 
reliable operation over very high-speed paths, including satellite environments. RFC- 
1323 support can be configured through the CLI and is enabled by default. 
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To enable or disable RFC-1323 support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip rfc-1323 {enable | disable} 

TCP NewReno 

NewReno is a modification of the Reno algorithm. TCP NewReno improves TCP 
performance during fast retransmit and fast recovery when multiple packets are dropped 
from a single window of data. TCP NewReno support is enabled by default. 

To enable or disable TCP NewReno support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip tcp-newreno {enable | disable} 

ICMP Broadcast Echo Support 

Disabling the ICMP broadcast echo command can prevent the SG appliance from 
participating in a Smurf Attack. A Smurf attack is a type of Denial-of-Service (DoS) attack, 
where the attacker sends an ICMP echo request packet to an IP broadcast address. This is 
the same type of packet sent in the ping command, but the destination IP is broadcast 
instead of unicast. If all the hosts on the network send echo reply packets to the ICMP 
echo request packets that were sent to the broadcast address, the network is jammed with 
ICMP echo reply packets, making the network unusable. By disabling ICMP broadcast 
echo response, the SG appliance does not participate in the Smurf Attack. 

This setting is disabled by default. 

To enable or disable ICMP broadcast echo support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-bcast-echo {enable | disable} 

For more information on preventing DDoS attacks, see Chapter 3: "Attack Detection" on 
page 53. 

ICMP Timestamp Echo Support 

By disabling the ICMP timestamp echo commands, you can prevent an attacker from 
being able to reverse engineer some details of your network infrastructure. 

For example, disabling the ICMP timestamp echo commands prevents an attack that 
occurs when the SG appliance responds to an ICMP timestamp request by accurately 
determining the target's clock state, allowing an attacker to more effectively attack certain 
time-based pseudo-random number generators (PRNGs) and the authentication systems 
on which they rely. 

This setting is disabled by default. 

To enable or disable ICMP Timestamp echo support: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip icmp-timestamp-echo {enable | disable} 
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TCP Window Size 

Adjusting the TCP window-size regulates the amount of unacknowledged data that the 
SG appliance receives before sending an acknowledgement. 

To configure the TCP window size: 

At the (config) command prompt, enter the following command: 

SGOS# (config) tcp-ip window-size window_size 

where window_size indicates the number of bytes allowed before acknowledgement 
(the value must be between 8192 and 4194304). 

PMTU Discovery 

PMTU (Path Maximum Transmission Unit) is a mechanism designed to discover the 
largest packet size sent that is not fragmented anywhere along the path between two 
communicating appliances that are not directly attached to the same link. 

An SG appliance that is not running PMTU might send packets larger than that allowed by 
the path, resulting in packet fragmentation at intermediate routers. Packet fragmentation 
affects performance and can cause packet discards in routers that are temporarily 
overtaxed. 

An SG appliance doing PMTU sets the Do-Not-Fragment bit in the IP header when 
transmitting packets. If fragmentation becomes necessary before the packets arrive at the 
second SG appliance, a router along the path discards the packets and returns an ICMP 
Host Unreachable error message, with the error condition of Needs-Fragmentation, to 
the original SG appliance. The first SG appliance then reduces the PMTU size and re- 
transmits the transmissions. 

The discovery period temporarily ends when the SG appliance estimates the PMTU is low 
enough that its packets can be delivered without fragmentation or when the SG appliance 
stops setting the Do-Not-Fragment bit. 

Following discovery and rediscovery, the size of the packets that are transferred between 
the two communicating nodes dynamically adjust to a size allowable by the path, which 
might contain multiple segments of various types of physical networks. 

PMTU is disabled by default. 

To configure PMTU discovery: 

At the (config) command prompt: 

SGOS# (config) tcp-ip pmtu-discovery enable | disable 

TCP Time Wait 

When a TCP connection is closed (such as when a user enters quit for an FTP session), the 
TCP connection remains in the TIME WAIT state for twice the Maximum Segment 
Lifetime (MSL) before completely removing the connection control block. 

The TIME WAIT state allows an end point (one end of the connection) to remove remnant 
packets from the old connection, eliminating the situation where packets from a previous 
connection are accepted as valid packets in a new connection. 

The MSL defines how long a packet can remain in transit in the network. The value of 
MSL is not standardized; the default value is assigned according to the specific 
implementation. 
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To change the MSL value, enter the following commands at the (config) command 
prompt: 

SGOS# (config) tcp-ip tcp-2msl seconds 

where seconds is the length of time you chose for the 2MSL value. Valid values are 1 

to 16380 inclusive. 

TCP Loss Recovery Mode 

A new TCP algorithm helps to recover throughput efficiently after packet losses occur and 
also addresses performance problems due to a single packet loss during a large transfer 
over long delay pipes. The feature is enhanced by default. 

To enable the algorithm: 

SGOS# (config) tcp-ip tcp-loss-recovery-mode {enhanced | aggressive} 

To disable the algorithm: 

SGOS# (config) tcp-ip tcp-loss-recovery-mode {normal} 

Viewing the TCP/IP Configuration 

To view the TCP/IP configuration: 

SGOS# (config) show tcp-ip 
RFC-1323 support: 

TCP Newreno support: 

IP forwarding: 

ICMP beast echo response: 

ICMP timestamp echo response 
Path MTU Discovery: 

TCP 2MSL timeout: 

TCP window size: 

TCP Loss Recovery Mode: 



enabled 
disabled 
disabled 
disabled 
: disabled 
disabled 
120 seconds 
65535 bytes 
Aggressive 



236 



Chapter 16: Virtual IP Addresses 



Virtual IP (VIP) addresses are addresses assigned to a system (but not an interface) that 
are recognized by other systems on the network. Up to 255 VIPs can be configured on 
each SG appliance. They have several uses: 

□ Assign multiple identities to a system on the same or different network, partitioning 
the box in to separate logical entities for resource sharing or load sharing. 

□ Create an HTTPS Console to allow multiple, simultaneous, secure connections to 
the system. 

□ Direct authentication challenges to different realms. 

□ Set up failover among multiple SG appliances on the same subnet. 

Note: For information on creating an HTTPS Console, refer to Volume 2: Proxies and 
Proxy Services ; for information on using VIPs with authentication realms, refer to 
Volume 4: Securing the Blue Coat SG Appliance-, to use VIPs with failover, see Chapter 7: 
"Configuring Failover" on page 97. 



To create a VIP: 

1. Select Configuration > Network > Advanced > VIPs. 

2. Click New. 

3. Enter the virtual IP address you want to use. It can be any IP address, except a 
multicast address. (A multicast address is a group address, not an individual IP 
address.) 



Note: You cannot create a VIP address that is the IP address used by the origin 
content server. You must assign a different address on the SG appliance, and use 
DNS or forwarding to point to the origin content server's real IP address. 



4. Click OK. 

5. Click Apply to commit the changes to the SG appliance. 
The VIP address can now be used. 



Related CLI Syntax to manage a VIP 

SGOS# (config) virtual address ipaddress 
SGOS# (config) virtual no address ip_address 
SGOS# (config) virtual clear 
SGOS# (config) show virtual 
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Chapter 1 7; WCCP Settings 



The SGOS software can be configured to participate in a WCCP (Web Cache Control 
Protocol) scheme, in which a WCCP-capable router collaborates with a set of WCCP- 
configured SG appliances to service requests. 



Overview 

WCCP is a C i sco -d evel oped protocol that allows you to establish redirection of the 
traffic that flows through routers. 

The main benefits of using WCCP are: 

□ Scalability. With no reconfiguration overhead, redirected traffic can be 
automatically distributed to up to 32 appliances. 

□ Redirection safeguards. If no appliances are available, redirection stops and the 
router forwards traffic to the original destination address. 

WCCP has two versions, version 1 and version 2, both of which are supported by Blue 
Coat. However, only one protocol version can be active on the SG appliance at a time. 
The active WCCP protocol set up in the SG configuration file must match the version 
running on the WCCP router. 

For information on using WCCP Version 1, see Appendix C: "Using WCCP" on page 
267. 

Using WCCP and Transparent Redirection 

A WCCP-capable router operates in conjunction with the appliances to transparently 
redirect traffic to a set of caches that participate in the specified WCCP protocol. IP 
packets are redirected based on fields within each packet. For instance, WCCP version 
1 only redirects destination TCP port 80 (default HTTP traffic) IP packets. WCCP 
version 2 allows you to redirect traffic from other ports and protocols. 

Load balancing is achieved through a redirection hash table to determine which SG 
appliance receives the redirected packet. 

WCCP Version 2 

For Cisco routers using WCCP version 2, minimum IOS releases are 12.0(3)T and 
12.0(4). Release 12.0(5) and later releases support WCCP versions 1 and 2. Ensure that 
you use the correct IOS software for the router and that you have a match between the 
SG configuration WCCP version number and router protocol version number. 

WCCP version 2 protocol offers the same capabilities as version 1, along with increased 
protocol security and multicast protocol broadcasts. Version 2 multicasting allows 
caches and routers to discover each other through a common multicast service group 
and matching passwords. In addition, up to 32 WCCP-capable routers can 
transparently redirect traffic to a set of up to 32 appliances. Version 2 WCCP-capable 
routers are capable of redirecting IP traffic to a set of appliances based on various fields 
within those packets. 
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Version 2 allows routers and caches to participate in multiple, simultaneous service 
groups. Routers can transparently redirect IP packets based on their formats. For example, 
one service group could redirect HTTP traffic and another could redirect FTP traffic. 



Note: Blue Coat recommends that WCCP-compliant caches from different vendors be 
kept separate and that only one vendor's routers be used in a service group. 



One of the caches participating in the WCCP service group is automatically elected to 
configure the home router's redirection tables. This way, caches can be transparently 
added and removed from the WCCP service group without requiring operator 
intervention. WCCP version 2 supports multiple service groups. 

The figure below illustrates a WCCP version 2 implementation using multiple routers and 
appliances. In this scenario, routers 1 through n and caches 1 through m participate in the 
same service group. As in version 1, an appliance from the group is selected to define the 
redirection hash table in all routers for all caches. All caches periodically communicate 
with all routers to verify WCCP protocol synchronization and appliance and router 
availability within the service group. In return, each router responds to caches with 
information as to what caches and discovered routers are available in the service group. 




Figure 17-1 . A Version 2 Configuration Using Packet Redirection to Multiple Routers and Caches 



Procedure Overview 

Two tasks must be completed to get WCCP running: 

□ Configuring the router 

□ Configuring the SG appliance 

To do initial router configuration: 

1. From the router (config) mode, tell WCCP which service group you want use. The 
Web-cache service group redirects port 80 (HTTP) traffic only. 

Router (config) #ip weep web-cache 

2. Enter the (config-if) submode by telling WCCP which IP address to use. 

Router (config) # int interface 

where interface is the adapter interface with an IP address. The prompt changes to 
configuration interface submode. 
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3. Enable packet redirection on an outbound (Internet facing) interface. 

Router (config-if) # ip weep web-cache redirect out 

4. Prevent packets received on an adapter interface from being checked for redirection 
and allow the use of Blue Coat bypass lists. 

Router (config-if ) # ip weep redirect exclude in 

For more information on WCCP router configuration, see "Configuring a WCCP Version 2 
Service on the Router" on page 270. 

To create an SG appliance WCCP configuration file and enable WCCP: 

1. Create a WCCP configuration file through either the SG appliance's CLI inline 
commands or through a text editor. Make sure that the home router you enter here is 
the home router that was named in the router's configuration. If you do have a 
mismatch, you must correct it before continuing. See "Identifying a Home Router/ 
Router ID Mismatch" on page 281. 

For more information on creating a configuration file, see "Creating an SG Appliance 
WCCP Configuration File" on page 241. 

If you used the inline commands, you have completed WCCP configuration for both 
the router and the SG appliance and you have enabled WCCP on the SG appliance. 
No further steps are needed. 

2. If you used a text editor, copy the file to an HTTP server accessible to the SG 
appliance. 

3. Enable WCCP and download the configuration file to the SG appliance. 

SGOS# (config) weep enable 

SGOS# (config) weep path http://205.66.255.10/files/wccp.txt 
SGOS# (config) load weep-settings 



Note: You can also use the Management Console > Configuration > Network > 

Advanced > WCCP to install the WCCP configuration file and enable WCCP. 



The rest of this chapter discusses the SG appliance WCCP configuration file. For detailed 
information on using WCCP, see Appendix C: "Using WCCP" on page 267. 

Creating an SG Appliance WCCP Configuration File 

Once you have the router global and adapter interface settings complete, you must create 
a WCCP configuration file for the SG appliance. 



Note: The appliance does not ship with a default WCCP configuration file. 



These configurations should include the following: 

□ Identify the service group. 

□ Identify the queuing priorities for all defined service groups. 

□ Identify the protocol. 

□ Load balancing caches in a service group. 

□ Identify ports. 

□ Identify the home router as defined in the router configuration. 
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□ Identify the packet forwarding method. 

Before you can install the WCCP configuration, you must create a WCCP configuration 
file for the SG appliance. The appliance does not ship with a default WCCP configuration 
file. 

Understanding Packet Forwarding 

By default, Cisco's GRE encapsulation (Generic Routing Encapsulation) is used to 
forward packets from the WCCP router to the caches. If you have a version 2 WCCP 
router, you can alternatively use Layer 2 (L2) rewrites to forward packets, which is faster 
than GRE and saves network bandwidth. 

Using GRE, redirected packets are encapsulated in a new IP packet with a GRE header. 

Using L2, redirected packets are not encapsulated; the MAC address of the target cache 
replaces the packet's destination MAC address. This different way of directing packets 
saves you the overhead of creating the GRE packet at the router and decoding it at the 
cache. Also, it saves network bandwidth that would otherwise be consumed by the GRE 
header. The SG appliance also supports the L2 packet return method if the router software 
does. In this release, the packet return method always matches the packet forward 
method. 

If you want to continue using GRE, you need not change any settings. To use L2 packet 
redirection, you must add the forwarding option to the SG configuration file. 

If WCCP version 2 is supported, the router sends out a list of forwarding mechanisms 
supported by the router in the first WCCP2 i see you message. The cache responds with a 
WCCP2 here i am message. If the router does not send the list, the cache aborts its 
attempt to join the WCCP service group. If the method of forwarding mechanism is not 
supported by the router, the WCCP2 messages from the cache are ignored. 

Caveats for using L2 redirection: 

□ You must use WCCP version 2. 

□ If a cache is not connected directly to a router, the router does allow the cache to 
negotiate the rewrite method. 

□ The same rewrite method must be used for both packet forwarding and packet return. 

Understanding Cache Load Balancing 

If you use WCCP version 2, you can balance the load on the caches in a service group. 
When a router receives an IP packet for redirection, it hashes fields within the packet to 
yield an index within the hash table. The packet then is forwarded to the owner SG 
appliance for servicing. The proportion of redirection hash table assigned to each SG 
appliance can be altered to provide a form of load balancing between caches in a service 
group. 

A hash table is configured by a dynamically elected SG appliance participating in a 
service group, enabling the simultaneous interception of multiple protocols on multiple 
ports. You can configure up to 100 dynamic or standard service groups plus standard 
service groups. A single service can intercept up to eight port numbers. 

Each element in this 256-entry hash table refers to an active SG appliance within the 
service group. By default, each SG appliance is assigned roughly an even percentage of 
the 256-element redirection hash table. Multiple network cards within an SG appliance 
can participate in the same service group. To the routers and other caches, each adapter 
interface appears as a unique cache. Using this strategy, redirected traffic can be better 
distributed among network interfaces in a cache. 
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Using Figure 17-2, below, all caches would be assigned 1/m of the redirection hash table, 
but since Cache 2 and Cache 3 are physically located within the same appliance, that 
appliance is actually assigned 2/m of the redirection hash table. 




Figure 17-2. A Version 2 Configuration Using Multicast Packet Redirection to Multiple Routers, 
Multiple Caches, and a Service Group 



Assigning Percentages 

You can override the default of each SG appliance being assigned roughly an even 
percentage; the relative distribution of the redirection hash table can be specified for each 
cache. Multiple hash-distributions are supported. Also, all, none, or part of a source and/ 
or destination IP address or port number can be used in the hash. Each SG appliance can 
be assigned a primary-hash-weight value to determine the proportion of the 256-element 
hash table to be assigned. 

If all caches are configured with a 0 primary-hash-weight value (the default) then each SG 
appliance is assigned an equal proportion of the redirection hash table. However, if any 
SG appliance is configured with a non-zero primary-hash-weight, each SG appliance is 
assigned a relative proportion of the table. 

For instance, consider a configuration with five caches that use a primary-hash-weight 
defined as {25, 200, 0, 50, 25). The total requested weight value is 25+200+0+50+25=300 
and, therefore, the proportion of the hash table assigned to each SG appliance is 25/300, 
200/300, 0/300, 50/300, and 25/300. 

Because one cache did not specify a non-zero primary-hash-weight, that cache is assigned 
any elements within the redirection hash table and, therefore, does not receive any 
redirected traffic. Also, the hash weight can be specified for each caching member within a 
SG appliance. In Figure 17-2, Cache 2 and Cache 3 can be assigned different weight values. 

Alternate Hash Table 

In some cases, a Web site becomes an Internet hot spot, receiving a disproportional number 
of client traffic relative to other sites. This situation can cause a larger request load on a 
specific SG appliance because the hash element associated with the popular site receives 
more activity than other hash elements. 
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To balance the redirection traffic load among the caches, a service group can be configured 
to use an alternate hash function when the number of GRE packets forwarded to the cache 
exceeds a certain number. (If you use L2 forwarding, the SG appliance counts MAC 
addresses.) Therefore, when a router receives an IP packet that hashes to an element 
flagged as a hot spot, the alternate hash function is computed. The appliance specified by 
the new index in the redirection hash table receives the redirected packet. 

Each SG appliance can dynamically determine a hot spot within its assigned portion of the 
redirection hash table. 

Alternate hash tables are only used for dynamic service groups that specify alternate-hash 
flags within their service-flags. The default Web-cache service group cannot use an 
alternate hash table. Instead, a comparable dynamic service group must be created. 

To use hot spot detection, the SG appliance's WCCP configuration file must specify: 

service-flags source-ip-hash 

service -flags destination-port- alternate-hash 

Creating a Configuration File 

An example of a file using a dynamic service, as opposed to the default Web-cache service, 
is shown below: 

If using the default Web-cache service, the service group settings priority, protocol, 
service flags, and ports are not used. 

weep enable 
weep version 2 
service-group 9 
forwarding-type L2 
priority 1 
protocol 6 

service -flags destination- ip- hash 
service-flags ports-defined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home-router 10.16.18.2 
end 

You can create a configuration file customized for the environment two ways: CLI inline 
commands or through a text file. In either case, the configuration file must include the 
information required by the commands below. 

Syntax to create a customized configuration file: 

service-group {web-cache | service-number} 

[priority priority-number] 

[protocol protocol-number] 

[service- flags hash-bit- identifier] 

[ports portl ... port8] 

home-router [ip-address | domain-name] 
interface [interface-number] 

[password string] 

[primary-hash-weight interface-number value] 
forwarding-type [GRE | L2] 

Using Optional Negation Syntax, you can create an alternative WCCP configuration file 
using these negative commands; this is especially helpful when testing and debugging. 
This functionality enables you to change some of the configuration settings without 
altering or reloading the main configuration file. 
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[no] service-group [web-cache | service-number } 
[priority priority-number] 

[protocol protocol-number ] 

[no] service-flags hash-bit-identifier 
[ports portl ...port8] 

home-router [ip-address \ domain-name] 
[multicast-ttl [ttl_value]] 

[no] interface [interface-number] 

[password string \ no password] 
[primary-hash-weight interface-number value] 

where: 



web-cache 


Enables the Web cache service group. If using the Web-cache service group for 
WCCP, the dynamic service group settings (priority, protocol, service 
flags, and ports) are not applicable. 


service-number 


The identification number of the dynamic service group being controlled by the 
router. Services are identified using a value from 0 to 99. The reverse-proxy service 
is indicated using the value 99. 


priori ty-number 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) Establishes queuing priorities for all defined 
service groups, based on a priority number from 0 through 255, inclusive. 


protocol-number 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number . ) Number of an Internet protocol. Protocol- 
number must be an integer in the range 0 through 255, inclusive, representing an 
IP protocol number. 


hash-bit -identifier 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) Sets the hash index, for load balancing purposes. 

The key associated with the hash-bit-identifier you specify is hashed to 
produce the primary redirection hash table index. For instance, if only the 
destination-ip-hash flag is set, then the packet destination IP address is used 
to determine the index. The index is constructed by starting with an initial value of 
zero and then computing an exclusive OR (XOR) of the fields specified in the hash- 
bit identifier. 

If alternative hashing has been enabled, any alternate hash flags are processed in 
the same way and produce a secondary redirection hash table index. Alternate 
hash flags end with the suffix "-alternate-hash." 

For more information using the hashing table, see "Understanding Cache Load 
Balancing" on page 242. 


source- ip -hash 
(hash-bit- identifier) 


Sets the source IP bit definition within the redirection hash table index. 


destination-ip-hash 

(hash-bit-identifier) 


Sets the source IP bit definition within the redirection hash table index. 


source-port -hash 
(hash-bit- identifier) 


Sets the source port bit definition within the redirection hash table index. 


destination-port-hash 
(hash-bit- identifier) 


Sets the destination port bit definition within the redirection hash table index. 


ports-def ined 
(hash-bit- identifier) 


Sets the port bit definition within the redirection hash table index. 
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ports-source 
(hash-bit- identifier) 


Sets the source port bit definition within the redirection hash table index. 


source- ip-alternate- 
hash 

(hash-bit- identifier) 


Sets the alternate source IP bit definition within the redirection hash table index. 


destination-ip- 
alternate-hash 
(hash-bit- identifier) 


Sets the alternate destination IP bit definition within the redirection hash table 
index. 


source-port- 
alternate -hash 

(hash-bit- identifier) 


The alternate source port bit definition within the redirection hash table index. 


destination-port- 
alternate -hash 
(hash-bit- identifier) 


Sets the alternate destination port bit definition within the redirection hash table 
index. 


multicast-ttl 


Sets the multicast TTL value per WCCP service group. The value must be set 
between 1 and 255. 

If the multicast TTL value is not set, the default value is 1. If the home-router 
address is not multicast, this command is non-operational. 


portl...port8 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) A zero-terminated list of TCP port identifiers. 

Note that this must be a list of exactly eight ports. 

If the service-flags ports-defined flag is set, packets are matched against the set of 
ports supplied. If the service-flags ports-source flag is set, the ports are 
assumed to be source ports. Otherwise, the ports are assumed to be destination 
ports. 


ip-address 


Indicates the IP address of your network’s home router. For version 2, ip- 
address can be a multicast address. (Multicast addresses are in the range 
224 . 0 . 0 . 0 to 239.255.255.255, inclusive.) 

In version 2, multiple IP addresses can be specified for unicast addressing. For 
multicast addresses, only one IP address can be specified per service group. 

If you choose to specify the home router IP address, it is important that the actual 
home router IP address and the home router IP address specified in this SG 
configuration file match. If you do not already know the IP address of the home 
router, you can easily determine it from the router CLI by using the show ip 
weep command. 


domain-name 


Specifies the domain name of your network's home router. Domain-name must be 
a valid domain name string that successfully resolves on DNS lookup. 


inter face -number 


Specifies the adapter interface number for the service group. You cannot use a 
colon (0 : 0 or 0 : 1 , for example). 


string 


(Applies to a dynamic service group only. A dynamic service group is one 
identified by a service number.) String can be at least one, and not more than eight, 
alphanumeric characters long. 

The password string specified here must match the password string declared for 
the router. 


inter face -number 


(When used with the hash identifiers) Specifies the adapter interface to which the 
weight factor is applied to alter the distribution of the primary hash table. 
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value 


Specifies the weight factor value (0 through 255) that is applied to the adapter 
interface specified to alter the distribution of the primary hash table. 


for war ding- type 
[ GRE | L2 ] 


Switches between GRE encapsulation (the default) and L2 MAC address rewrite 
for forwarding packets. If this command is not present, GRE encapsulation is used. 



You can create a configuration file customized for the environment through the CLI inline 
commands or through a text file. The CLI inline commands enable WCCP on the SG 
appliance immediately; the drawback is that if any information changes, you must re- 
create the whole file using the inline command. With a text file, if any information 
changes, you can change the individual line; the drawback is that you must download the 
file again from an HTTP server to the SG appliance. 

To use CLI commands to create a configuration file, continue with the next procedure. To 
use a text editor to create a configuration file, continue with "Creating a Configuration 
File using a Text File" on page 247. 

Creating a Configuration File using CLi Inline Commands 

For examples of various types of WCCP configurations, see Appendix C: "Using WCCP” 
on page 267. 

If you choose to configure through the CLI and the inline command, refer to the example 
below: 

SGOS# configure terminal 

SGOS# (config) inline weep eof 

where eof marks the beginning and end of the inline commands. 

For example: 

SGOS# (config) inline weep eof 
weep enable 
weep version 2 
service-group 9 
forwarding-type L2 
priority 1 
protocol 6 

service-flags destination- ip-hash 
service-flags ports-def ined 
ports 80 21 1755 554 80 80 80 80 
interface 6 

home-router 10.16.18.2 

end 

eof 

You created a WCCP configuration file and enabled WCCP on the SG appliance. WCCP 
setup is complete. 

Creating a Configuration File using a Text File 

If you create a configuration file using a text editor, assign the file the extension . txt. The 
following are SG configuration file rules: 

□ Only one command (and any associated parameters) is permitted, per line. 

□ Comments must begin with a semicolon ( ; ) or a pound sign (#). 

□ Comments can begin in any column; however, all characters from the beginning of the 
comment to the end of the line are considered part of the comment and, therefore, are 
ignored. 
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For examples of various types of WCCP configurations, see Appendix C: "Using WCCP” 
on page 267. 

To create a configuration file using a text editor and load the file on an SG 
appliance: 

1. Open a text editor. 

2. Using the commands described in "Syntax to create a customized configuration file:" 
on page 244, enter the arguments you need. 

3. Copy the configuration file to an FITTP server so that it can be downloaded to the SG 
appliance. 

4. Enable WCCP and download the WCCP configuration file using the following syntax: 

weep {enable | disable | no} [path config-file-url ] | [version version- 

number] 

where: 



enable 


Enables WCCP on the SG appliance. 


disable 


Disables WCCP on the SG appliance. 


no 


Indicates that you want to clear the current WCCP configuration settings. 


config-file-url 


Specifies the SG WCCP configuration file or alternate configuration file. 


version -n umber 


Indicates the version of WCCP that your router is configured to use. If 
version version-number is omitted, it is assumed to be 2. 



For example: 

SGOS# (config) weep enable 

SGOS# (config) weep path http://205.66.255.10/files/wccp.txt 
SGOS# (config) load weep-settings 



Statistics 



WCCP Statistics can be viewed by going to Management Console > Statistics > Advanced 
and scrolling down to the WCCP Statistics. 

The definitions for the WCCP statistics are defined as: 



WCCPO 


Current time 


WCCP1 


Last stats reset time 


WCCP2 


Packets sent 


WCCP3 


Bytes sent 


WCCP4 


Packet received 


WCCP5 


Bytes received 


WCCP 6 


Bad packets received 


WCCP6 . 1 


Receive error 


WCCP6.2 


Unknown type 


WCCP6.3 


Total size too small 


WCCP6 . 4 


Header too small 


WCCP6 . 5 


Bad version 


WCCP6 . 6 


Bad security comp 


WCCP6 . 7 


Bad service info comp 


WCCP6 . 8 


Bad query info comp 


WCCP6 . 9 


Unknown group 


WCCP6 .10 


Unsolicited query 
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WCCP6 .11 


Bad router id comp 


WCCP6 .12 


Bad router view comp 


WCCP6 .13 


Service group mismatch 


WCCP6 .14 


Forwarding type mismatch 


WCCP6 .15 


Assignment type mismatch 


WCCP6 .16 


Capability mismatch 


WCCP7 


Bad security packets 


WCCP8 


Internal errors 


WCCP8 . 1 


Failed to send 


WCCP8 .2 


Add RID for router 


WCCP8 .3 


Alloc query member 


WCCP8 . 4 


Alloc query timer 


WCCP8 . 5 


Add router to group 


WCCP8 . 6 


Add cache to group 


WCCP8 . 7 


Alloc active caches 


WCCP8 . 8 


Bucket reassignment 


WCCP 9 


Allocated blocks 



Notes 

If you use IP spoofing with WCCP, do the following for best results: 

□ The ip weep redirect exclude in command should be applied to the adapter to 
which the SG appliance is attached. 

□ For L2 forwarding, the SG appliance should be directly connected to the router 
interface. 
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A 



access control list 


Allows or denies specific IP addresses access to a server. 


access log 


A list of all the requests sent to an appliance. You can read an access log using any of 
the popular log-reporting programs. When a client uses HTTP streaming, the 
streaming entry goes to the same access log. 


account 


A named entity that has purchased the appliance or the Entitlements from Blue Coat. 


activation code 


A string of approximately 10 characters that is generated and mailed to customers 
when they purchase the appliance. 


active content stripping 


Provides a way to identify potentially dangerous mobile or active content and 
scripts, and strip them out of a response. 


active content types 


Used in the Visual Policy Manager. Referring to Web Access policies, you can create 
and name lists of active content types to be stripped from Web pages. You have the 
additional option of specifying a customized message to be displayed to the user 


administration access policy 


A policy layer that determines who can access the SG appliance to perform 
administrative tasks. 


administration 
authentication policy 


A policy layer that determines how administrators accessing the SG appliance must 
authenticate. 


Application Delivery 
Network (ADN) 


A WAN that has been optimized for acceleration and compression by Blue Coat. This 
network can also be secured through the use of appliance certificates. An ADN 
network is composed of an ADN manager and backup ADN manager, ADN nodes, 
and a network configuration that matches the environment. 


ADN backup manager 


Takes over for the ADN manager in the event it becomes unavailable. See ADN 
manager. 


ADN manager 


Responsible for publishing the routing table to SG Clients (and to other SG 
appliances). 


ADN optimize attribute 


Controls whether to optimize bandwidth usage when connecting upstream using an 
ADN tunnel. 


asx rewrite 


Allows you to rewrite URLs and then direct a client's subsequent request to the new 
URL. One of the main applications of ASX file rewrites is to provide explicit proxy- 
like support for Windows Media Player 6.4, which cannot set explicit proxy mode for 
protocols other than HTTP. 


audit 


A log that provides a record of who accessed what and how. 
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authenticate-401 attribute 


All transparent and explicit requests received on the port always use transparent 
authentication (cookie or IP, depending on the configuration). This is especially 
useful to force transparent proxy authentication in some proxy-chaining scenarios 


authenticated content 


Cached content that requires authentication at the origin content server (OCS). 
Supported authentication types for cached data include basic authentication and 
IWA (or NTLM). 


authentication 


Allows you to verify the identity of a user. In its simplest form, this is done through 
usernames and passwords. Much more stringent authentication can be employed 
using digital certificates that have been issued and verified by a Certificate Authority. 
See also basic authentication, proxy authentication, and SSL authentication. 


authentication realm 


Authenticates and authorizes users to access SG services using either explicit proxy 
or transparent proxy mode. These realms integrate third-party vendors, such as 
LDAP, Windows, and Novell, with the Blue Coat operating system. 


authorization 


The permissions given to an authenticated user. 



B 



bandwidth class 


A defined unit of bandwidth allocation. 


bandwidth class hierarchy 


Bandwidth classes can be grouped together in a class hierarchy, which is a tree 
structure that specifies the relationship among different classes. You create a 
hierarchy by creating at least one parent class and assigning other classes to be its 
children. 


bandwidth management 


Classify, control, and, if needed, limit the amount of bandwidth used by network 
traffic flowing in or out of an SG appliance. 


basic authentication 


The standard authentication for communicating with the target as identified in the 
URL. 


BCAAA 


Blue Coat Authentication and Authorization Agent. Allows SGOS 5.x to manage 
authentication and authorization for IWA, CA eTrust SiteMinder realms, Oracle 
COREid, Novell, and Windows realms. The agent is installed and configured 
separately from SGOS 5.x and is available from the Blue Coat Web site. 


BCLP 


Blue Coat Licensing Portal. 


byte-range support 


The ability of the SG appliance to respond to byte-range requests (requests with a 
Range : HTTP header). 



C 



cache 


An "object store,” either hardware or software, that stores information (objects) for 
later retrieval. The first time the object is requested, it is stored, making subsequent 
requests for the same information much faster. 

A cache helps reduce the response time and network bandwidth consumption on 
future, equivalent requests. The SG appliance serves as a cache by storing content 
from many users to minimize response time and prevent extraneous network traffic. 


cache control 


Allows you to configure which content the SG appliance stores. 
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cache efficiency 


A tab found on the Statistics pages of the Management Console that shows the 
percent of objects served from cache, the percent loaded from the network, and the 
percent that were non-cacheable. 


cache hit 


Occurs when the SG appliance receives a request for an object and can serve the 
request from the cache without a trip to the origin server. 


cache miss 


Occurs when the appliance receives a request for an object that is not in the cache. 
The appliance must then fetch the requested object from the origin server. . 


cache object 


Cache contents includes all objects currently stored by the SG appliance. Cache 
objects are not cleared when the SG appliance is powered off. 


Certificate Authority (CA) 


A trusted, third-party organization or company that issues digital certificates used to 
create digital signatures and public key/ private key pairs. The role of the CA is to 
guarantee that the individuals or company representatives who are granted a unique 
certificate are who they claim to be. 


child class (bandwidth gain) 


The child of a parent class is dependent upon that parent class for available 
bandwidth (they share the bandwidth in proportion to their minimum /maximum 
bandwidth values and priority levels). A child class with siblings (classes with the 
same parent class) shares bandwidth with those siblings in the same manner. 


client consent certificates 


A certificate that indicates acceptance or denial of consent to decrypt an end user's 
HTTPS request. 


client-side transparency 


A way of replacing the appliance IP address with the Web server IP address for all 
port 80 traffic destined to go to the client. This effectively conceals the SG appliance 
address from the client and conceals the identity of the client from the Web server. 


concentrator 


An SG appliance, usually located in a data center, that provides access to data center 
resources, such as file servers. 


content filtering 


A way of controlling which content is delivered to certain users. SG appliances can 
filter content based on content categories (such as gambling, games, and so on), type 
(such as http, ftp, streaming, and mime type), identity (user, group, network), or 
network conditions. You can filter content using vendor-based filtering or by 
allowing or denying access to URLs. 



D 



default boot system 


The system that was successfully started last time. If a system fails to boot, the next 
most recent system that booted successfully becomes the default boot system. 


default proxy listener 


See proxy service (d efault). 


denial of service (DoS) 


A method that hackers use to prevent or deny legitimate users access to a computer, 
such as a Web server. DoS attacks typically send many request packets to a targeted 
Internet server, flooding the server’s resources and making the system unusable. Any 
system connected to the Internet and equipped with TCP-based network services is 
vulnerable to a DoS attack. 

The SG appliance resists DoS attacks launched by many common DoS tools. With a 
hardened TCP/IP stack, SG appliance resists common network attacks, including 
traffic flooding. 
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destination objects 


Used in Visual Policy Manager. These are the objects that define the target location of 
an entry type. 


detect protocol attribute 


Detects the protocol being used. Protocols that can be detected include: HTTP, P2P 
(eDonkey, BitTorrent, FastTrack, Gnutella), SSL, and Endpoint Mapper. 


diagnostic reporting 


Found in the Statistics pane, the Diagnostics tab allows you to control whether Daily 
Heartbeats and/ or Blue Coat Monitoring are enabled or disabled. 


directives 


Commands used in installable lists to configure forwarding and SOCKS gateway. 


DNS access 


A policy layer that determines how the SC appliance processes DNS requests. 


domain name system (DNS) 


An Internet service that translates domain names into IP addresses. See also private 
DNS or public DNS. 


dynamic bypass 


Provides a maintenance-free method for improving performance of the SC appliance 
by automatically compiling a list of requested URLs that return various kinds of 
errors. 


dynamic real-time rating 
(DRTR) 


Used in conjunction with the Blue Coat Web Filter (BCWF), DRTR (also known as 
dynamic categorization) provides real-time analysis and content categorization of 
requested Web pages to solve the problem of new and previously unknown 
uncategorized URLs — those not in the database. When a user requests a URL that has 
not already been categorized by the BCWF database (for example, a brand new Web 
site), the SC appliance dynamic categorization service analyzes elements of the 
requested content and assigns a category or categories. The dynamic service is 
consulted only when the installed BCWF database does not contain category 
information for an object. 



E 



early intercept attribute 


Controls whether the proxy responds to client TCP connection requests before 
connecting to the upstream server. When early intercept is disabled, the proxy delays 
responding to the client until after it has attempted to contact the server. 


ELFF-compatible format 


A log type defined by the W3C that is general enough to be used with any protocol. 


emulated certificates 


Certificates that are presented to the user by SG appliance when intercepting HTTPS 
requests. Blue Coat emulates the certificate from the server and signs it, copying the 
subjectName and expiration. The original certificate is used between the SG 
appliance and the server. 


encrypted log 


A log is encrypted using an external certificate associated with a private key. 
Encrypted logs can only be decrypted by someone with access to the private key. The 
private key is not accessible to the SG appliance. 


EULA 


End user license agreement. 


event logging 


Allows you to specify the types of system events logged, the size of the event log, and 
to configure Syslog monitoring. The appliance can also notify you by email if an 
event is logged. See also access logging. 
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explicit proxy 


A configuration in which the browser is explicitly configured to communicate with 
the proxy server for access to content. 

This is the default for the SG appliance, and requires configuration for both browser 
and the interface card. 


extended log file format 
(ELFF) 


A variant of the common log file format, which has two additional fields at the end of 
the line — the referer and the user agent fields. 



F 



fail open /closed 


Failing open or closed applies to forwarding hosts and groups and SOCKS gateways. 
Fail open or closed applies when health checks are showing sick for each forwarding 
or SOCKS gateway target in the applicable fail-over sequence. If no systems are 
healthy, the SG appliance fails open or closed, depending on the configuration. If 
closed, the connection attempt simply fails. 

If open, an attempt is made to connect without using any forwarding target (or 
SOCKS gateway). Fail open is usually a security risk; fail closed is the default if no 
setting is specified. 


filtering 


See content filtering. 


forward proxy 


A proxy server deployed close to the clients and used to access many servers. A 
forward proxy can be explicit or transparent. 


FTP 


See Native FTP; Web FTP. 



G 



gateway 


A device that serves as entrance and exit into a communications network. 



H 



hardware serial number 


A string that uniquely identifies the appliance; it is assigned to each unit in 
manufacturing. 


health check tests 


The method of determining network connectivity, target responsiveness, and basic 
functionality. The following tests are supported: 

• ICMP 

• TCP 

• SSL 

• HTTP 

• HTTPS 

• Group 

• Composite and reference to a composite result 

• ICAP 

• Websense 

• DRTR rating service 
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health check type 


The kind of device or service the specific health check tests. The following types are 
supported: 

• Forwarding host and forwarding group 

• SOCKS gateway and SOCKS gateway group 

• CAP service and ICAP service group 

• Websense off -box service and Websense off-box service group 

• DRTR rating service 

• User-defined host and a user-defined composite 


heartbeat 


Messages sent once every 24 hours that contain the statistical and configuration data 
for the SG appliance, indicating its health. Heartbeats are commonly sent to system 
administrators and to Blue Coat. Heartbeats contain no private information, only 
aggregate statistics useful for pre-emptively diagnosing support issues. 

The SG appliance sends emergency heartbeats whenever it is rebooted. Emergency 
heartbeats contain core dump and restart flags in addition to daily heartbeat 
information. 


host affinity 


The attempt to direct multiple connections by a single user to the same group 
member. Host affinity is closely tied to load balancing behavior; both should be 
configured if load balancing is important. 


host affinity timeout 
| 


The host affinity timeout determines how long a user remains idle before the 
connection is closed. The timeout value checks the user's IP address, SSL ID, or 
cookie in the host affinity table. 


inbound traffic (bandwidth 
gain) 


Network packets flowing into the SG appliance. Inbound traffic mainly consists of 
the following: 

• Server inbound: Packets originating at the origin content server (OCS) and sent to 
the SG appliance to load a Web object. 

• Client inbound: Packets originating at the client and sent to the SG appliance for 
Web requests. 


installable lists 


Installable lists, comprised of directives, can be placed onto the SG appliance in one 
of the following ways: 

• Creating the list using the SG text editor 

• Placing the list at an accessible URL 

• Downloading the directives file from the local system 


integrated host timeout 


An integrated host is an origin content server (OCS) that has been added to the health 
check list. The host, added through the integrate new hosts property, ages out 
of the integrated host table after being idle for the specified time. The default is 60 
minutes. 


intervals 


Time period from the completion of one health check to the start of the next health 
check. 


IP reflection 


Determines how the client IP address is presented to the origin server for explicitly 
proxied requests. All proxy services contain a reflect-ip attribute, which enables or 
disables sending of client's IP address instead of the SG's IP address. 
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issuer keyring 


The keyring used by the SG appliance to sign emulated certificates. The keyring is 
configured on the appliance and managed through policy. 



L 



licensable component (LC) 


(Software) A subcomponent of a license; it is an option that enables or disables a 
specific feature. 


license 


Provides both the right and the ability to use certain software functions within an AV 
(or SG) appliance. The license key defines and controls the license, which is owned 
by an account. 


listener 


The service that is listening on a specific port. A listener can be identified by any 
destination IP/ subnet and port range. Multiple listeners can be added to each 
service. 


live content 


Also called live broadcast. Used in streaming, it indicates that the content is being 
delivered fresh. 


LKF 


License key file. 


load balancing 


A way to share traffic requests among multiple upstream systems or multiple IP 
addresses on a single host. 


local bypass list 


A list you create and maintain on your network. You can use a local bypass list alone 
or in conjunction with a central bypass list. See bypass list. 


local policy file 


Written by enterprises (as opposed to the central policy file written by Blue Coat); 
used to create company- and department-specific advanced policies written in the 
Blue Coat Policy Language (CPL). 


log facility 


A separate log that contains a single logical file and supports a single log format. It 
also contains the file's configuration and upload schedule information as well as 
other configurable information such as how often to rotate (switch to a new log) the 
logs at the destination, any passwords needed, and the point at which the facility can 
be uploaded. 


log format 


The type of log that is used: NCSA/Common, SQUID, ELFF, SurfControl, or 
Websense. 

The proprietary log types each have a corresponding pre-defined log format that has 
been set up to produce exactly that type of log (these logs cannot be edited). In 
addition, a number of other ELFF type log formats are also pre-defined (im, main, 
p2p, ssl, streaming). These can be edited, but they start out with a useful set of log 
fields for logging particular protocols understood by the SG appliance. It is also 
possible to create new log formats of type ELFF or Custom which can contain any 
desired combination of log fields. 


log tail 


The access log tail shows the log entries as they get logged. With high traffic on the 
SG appliance, not all access log entries are necessarily displayed. However, you can 
view all access log information after uploading the log. 



M 



MACH5 


SGOS 5 MACH5 Edition. 
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Management Console 


A graphical Web interface that lets you to manage, configure, monitor, and upgrade 
the SG appliance from any location. The Management Console consists of a set of 
Web pages and Java applets stored on the SG appliance. The appliance acts as a Web 
server on the management port to serve these pages and applets. 


management information 
base (MIB) 


Defines the statistics that management systems can collect. A managed device 
(gateway) has one or more MIBs as well as one or more SNMP agents, which 
implements the information and management functionality defined by a specific 
MIB. 


maximum object size 


The maximum object size stored in the SG appliance. All objects retrieved that are 
greater than the maximum size are delivered to the client but are not stored in the SG 
appliance. 


MIME/FILE type filtering 


Allows organizations to implement Internet policies for both uploaded and 
downloaded content by MIME or FILE type. 


multi-bit rate 


The capability of a single stream to deliver multiple bit rates to clients requesting 
content from appliances from within varying levels of network conditions (such as 
different connecting bandwidths and traffic). 


multicast 


Used in streaming; the ability for hundreds or thousands of users to play a single 
stream. 


multicast aliases 


Used in streaming; a streaming command that specifies an alias for a multicast URL 
to receive an .nsc file. The .nsc files allows the multicast session to obtain the 
information in the control channel 


multicast station 


Used in streaming; a defined location on the proxy where the Windows Media player 
can retrieve streams. A multicast station enables multicast transmission of Windows 
Media content from the cache. The source of the multicast-delivered content can be a 
unicast-live source, a multicast (live) source, and simulated live (video-on-demand 
content converted to scheduled live content). 


multimedia content services 


Used in streaming; multimedia support includes Real Networks, Microsoft Windows 
Media, Apple QuickTime, MP3, and Flash. 



N 



name inputing 


Allows an SG appliance to resolve host names based on a partial name specification. 
When a host name is submitted to the DNS server, the DNS server resolves the name 
to an IP address. If the host name cannot be resolved, Blue Coat adds the first entry in 
the name-inputing list to the end of the host name and resubmits it to the DNS server 


native FTP 


Native FTP involves the client connecting (either explicitly or transparently) using 
the FTP protocol; the SG appliance then connects upstream through FTP (if 
necessary). 


NCSA common log format 


Blue Coat products are compatible with this log type, which contains only basic 
HTTP access information. 


network address translation 
(NAT) 


The process of translating private network (such as intranet) IP addresses to Internet 
IP addresses and vice versa. This methodology makes it possible to match private IP 
addresses to Internet IP addresses even when the number of private addresses 
outnumbers the pool of available Internet addresses. 
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non-cacheable objects 



.nsc file 
NTP 

O 

object (used in caching) 

object (used in Visual Policy 
Manager) 

object pipelining 

origin content server (OCS) 

outbound traffic (bandwidth 
gain) 

P 

PAC (Proxy 

AutoConfiguration) scripts 
packet capture (PCAP) 



A number of objects are not cached by the Blue Coat appliance because they are 
considered non-cacheable. You can add or delete the kinds of objects that the 
appliance considers non-cacheable. Some of the non-cacheable request types are: 

• Pragma no-cache, requests that specify non-cached objects, such as when you click 
refresh in the Web browser. 

• Password provided, requests that include a client password. 

• Data in request that include additional client data. 

• Not a GET request. 

Created from the multicast station definition and saved through the browser as a text 
file encoded in a Microsoft proprietary format. Without an .nsc file, the multicast 
station definition does not work. 

To manage objects in an appliance, an SG appliance must know the current Universal 
Time Coordinates (UTC) time. By default, the SG appliance attempts to connect to a 
Network Time Protocol (NTP) server to acquire the UTC time. SG appliance includes 
a list of NTP servers available on the Internet, and attempts to connect to them in the 
order they appear in the NTP server list on the NTP tab. 



An object is the item that is stored in an appliance. These objects can be frequently 
accessed content, content that has been placed there by content publishers, or Web 
pages, among other things. 

An object (sometimes referred to as a condition) is any collection or combination of 
entry types you can create individually (user, group, IP address/ subnet, and 
attribute). To be included in an object, an item must already be created as an 
individual entry. 

This patented algorithm opens as many simultaneous TCP connections as the origin 
server will allow and retrieves objects in parallel. The objects are then delivered from 
the appliance straight to the user's desktop as fast as the browser can request them. 

Also called origin server. This is the original source of the content that is being 
requested. An appliance needs the OCS to acquire data the first time, to check that 
the content being served is still fresh, and to authenticate users. 

Network packets flowing out of the SG appliance. Outbound traffic mainly consists 
of the following: 

• Client outbound: Packets sent to the client in response to a Web request. 

• Server outbound: Packets sent to an OCS or upstream proxy to request a service. 



Originally created by Netscape, PACs are a way to avoid requiring proxy hosts and 
port numbers to be entered for every protocol. You need only enter the URL. A PAC 
can be created with the needed information and the local browser can be directed to 
the PAC for information about proxy hosts and port numbers. 

Allows filtering on various attributes of the Ethernet frame to limit the amount of 
data collected. You can capture packets of Ethernet frames going into or leaving an 
SG appliance. 
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parent class (bandwidth 
gain) 


A class with at least one child. The parent class must share its bandwidth with its 
child classes in proportion to the minimum/ maximum bandwidth values or priority 
levels. 


passive mode data 
connections (PASV) 


Data connections initiated by an FTP client to an FTP server. 


pipelining 


See object pipelining. 


policies 


Groups of rules that let you manage Web access specific to the needs of an enterprise. 
Policies enhance SG appliance feature areas such as authentication and virus 
scanning, and let you control end-user Web access in your existing infrastructure. 

See also refresh policies. 


policy-based bypass list 


Used in policy. Allows a bypass based on the properties of the client, unlike static and 
dynamic bypass lists, which allow traffic to bypass the appliance based on 
destination IP address. See also bypass lists and dynamic bypass. 


policy layer 


A collection of rules created using Blue Coat CPL or with the VPM. 


pragma: no cache (PNC) 


A metatag in the header of a request that requires the appliance to forward a request 
to the origin server. This allows clients to always obtain a fresh copy (of the request?). 


proxy 


Caches content, filters traffic, monitors Internet and intranet resource usage, blocks 
specific Internet and intranet resources for individuals or groups, and enhances the 
quality of Internet or intranet user experiences. 

A proxy can also serve as an intermediary between a Web client and a Web server 
and can require authentication to allow identity based policy and logging for the 
client. 

The rules used to authenticate a client are based on the policies you create on the SG 
appliance, which can reference an existing security infrastructure — LDAP, RADIUS, 
IWA, and the like. 


Proxy Edition 


SGOS 5 Proxy Edition. 


proxy service 


The proxy service defines the ports, as well as other attributes, that are used by the 
proxies associated with the service. 


proxy service (default) 


The default proxy service is a service that intercepts all traffic not otherwise 
intercepted by other listeners. It only has one listener whose action can be set to 
bypass or intercept. No new listeners can be added to the default proxy service, and 
the default listener and service cannot be deleted. Service attributes can be changed. 


public key certificate 


An electronic document that encapsulates the public key of the certificate sender, 
identifies this sender, and aids the certificate receiver to verify the identity of the 
certificate sender. A certificate is often considered valid if it has been digitally signed 
by a well-known entity, which is called a Certificate Authority (such as VeriSign). 


public virtual IP (VIP) 


Maps multiple servers to one IP address and then propagates that information to the 
public DNS servers. Typically, there is a public VIP known to the public Internet that 
routes the packets internally to the private VIP. This enables you to "hide" your 
servers from the Internet. 
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real-time streaming protocol 
(RTSP) 


A standard method of transferring audio and video and other time-based media over 
Internet-technology based networks. The protocol is used to stream clips to any RTP- 
based client. 


reflect client IP attribute 


Enables the sending of the client's IP address instead of the SG's IP address to the 
upstream server. If you are using an application delivery network (ADN), this setting 
is enforced on the concentrator proxy through the Configuration > App. Delivery 
Network > Tunneling tab. 


registration 


An event that binds the appliance to an account, that is, it creates the Serial#, Account 
association. 


remote authentication dial- 
in user service (RADIUS) 


Authenticates user identity via passwords for network access. 


reverse proxy 


A proxy that acts as a front-end to a small number of pre-defined servers, typically to 
improve performance. Many clients can use it to access the small number of 
predefined servers. 


routing information protocol 
(RIP) 


Designed to select the fastest route to a destination. RIP support is built into Blue 
Coat appliances. 


router hops 


The number of jumps a packet takes when traversing the Internet. 



S 



secure shell (SSH) 


Also known as Secure Socket Shell. SSH is an interface and protocol that provides 
strong authentication and enables you to securely access a remote computer. Three 
utilities — login, ssh, and scp — comprise SSH. Security via SSH is accomplished using 
a digital certificate and password encryption. Remember that the Blue Coat SG 
appliance requires SSH1. An SG appliance supports a combined maximum of 16 
Telnet and SSH sessions. 


serial console 


A third-party device that can be connected to one or more Blue Coat appliances. 
Once connected, you can access and configure the appliance through the serial 
console, even when you cannot access the appliance directly. 


server certificate categories 


The hostname in a server certificate can be categorized by BCWF or another content 
filtering vendor to fit into categories such as banking, finance, sports. 


server portals 


Doorways that provide controlled access to a Web server or a collection of Web 
servers. You can configure Blue Coat SG appliances to be server portals by mapping a 
set of external URLs onto a set of internal URLs. 


server-side transparency 


The ability for the server to see client IP addresses, which enables accurate client- 
access records to be kept. When server-side transparency is enabled, the appliance 
retains client IP addresses for all port 80 traffic to and from the SG appliance. In this 
scheme, the client IP address is always revealed to the server. 


service attributes 


Define the parameters, such as explicit or transparent, cipher suite, and certificate 
verification, that the SG appliance uses for a particular service. . 
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SG appliance 


A Blue Coat security and cache box that can help manage security and content on a 
network. 


sibling class (bandwidth 
gain) 


A bandwidth class with the same parent class as another class. 


simple network 
management protocol 
(SNMP) 


The standard operations and maintenance protocol for the Internet. It uses MIBs, 
created or customized by Blue Coat, to handle (needs completion). 


simulated live 


Used in streaming. Defines playback of one or more video-on-demand files as a 
scheduled live event, which begins at a specified time. The content can be looped 
multiple times, or scheduled to start at multiple start times throughout the day. 


SmartReporter log type 


A proprietary ELFF log type that is compatible with the SmartFilter SmartReporter 
tool. 


SOCKS 


A proxy protocol for TCP/IP-based networking applications that allows users 
transparent access across the firewall. If you are using a SOCKS server for the 
primary or alternate forwarding gateway, you must specify the appliance's ID for the 
identification protocol used by the SOCKS gateway. The machine ID should be 
configured to be the same as the appliance's name. 


SOCKS proxy 


A generic way to proxy TCP and UDP protocols. The SG appliance supports both 
SOCKSv4/4a and SOCKSv5; however, because of increased username and password 
authentication capabilities and compression support. Blue Coat recommends that 
you use SOCKS v5. 


splash page 


Custom message page that displays the first time you start the client browser. 


split proxy 


Employs co-operative processing at the branch and the core to implement 
functionality that is not possible in a standalone proxy. Examples of split proxies 
include: 

• Mapi Proxy 

• SSL Proxy 


SQUID-compatible format 


A log type that was designed for cache statistics and is compatible with Blue Coat 
products. 


squid-native log format 


The Squid-compatible format contains one line for each request. 


SSL authentication 


Ensures that communication is with "trusted" sites only. Requires a certificate issued 
by a trusted third party (Certificate Authority). 


SSL interception 


Decrypting SSL connections. 


SSL proxy 


A proxy that can be used for any SSL traffic (HTTPS or not), in either forward or 
reverse proxy mode. 


static route 


A manually-configured route that specifies the transmission path a packet must 
follow, based on the packet's destination address. A static route specifies a 
transmission path to another network. 
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statistics 


Every Blue Coat appliance keeps statistics of the appliance hardware and the objects 
it stores. You can review the general summary, the volume, resources allocated, cache 
efficiency, cached contents, and custom URLs generated by the appliance for various 
kinds of logs. You can also check the event viewer for every event that occurred since 
the appliance booted. 


stream 


A flow of a single type of data, measured in kilobits per second (Kbps). A stream 
could be the sound track to a music video, for example. 


SurfControl log type 


A proprietary log type that is compatible with the SurfControl reporter tool. The 
SurfControl log format includes fully-qualified usernames when an NTLM realm 
provides authentication. The simple name is used for all other realm types. 


syslog 


An event-monitoring scheme that is especially popular in Unix environments. Most 
clients using Syslog have multiple devices sending messages to a single Syslog 
daemon. This allows viewing a single chronological event log of all of the devices 
assigned to the Syslog daemon. The Syslog format is: "Date Time Hostname Event." 


system cache 


The software cache on the appliance. When you clear the cache, all objects in the 
cache are set to expired. The objects are not immediately removed from memory or 
disk, but a subsequent request for any object requested is retrieved from the origin 
content server before it is served. 



T 



time-to-live (TTL) value 


Used in any situation where an expiration time is needed. For example, you do not 
want authentication to last beyond the current session and also want a failed 
command to time out instead of hanging the box forever. 


traffic flow 
(bandwidth gain) 


Also referred to as flow. A set of packets belonging to the same TCP/UDP connection 
that terminate at, originate at, or flow through the SG appliance. A single request 
from a client involves two separate connections. One of them is from the client to the 
SG appliance, and the other is from the SG appliance to the OCS. Within each of 
these connections, traffic flows in two directions — in one direction, packets flow out 
of the SG appliance (outbound traffic), and in the other direction, packets flow into 
the SG (inbound traffic). Connections can come from the client or the server. Thus, 
traffic can be classified into one of four types: 

• Server inbound 

• Server outbound 

• Client inbound 

• Client outbound 

These four traffic flows represent each of the four combinations described above. 
Each flow represents a single direction from a single connection. 


transmission control 
protocol (TCP) 


TCP, when used in conjunction with IP (Internet Protocol) enables users to send data, 
in the form of message units called packets, between computers over the Internet. 
TCP is responsible for tracking and handling, and reassembly of the packets; IP is 
responsible for packet delivery. 


transparent proxy 


A configuration in which traffic is redirected to the SG appliance without the 
knowledge of the client browser. No configuration is required on the browser, but 
network configuration, such as an L4 switch or a WCCP-compliant router, is 
required. 
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trial period 


Starting with the first boot, the trial period provides 60 days of free operation. All 
features are enabled during this time. 



U 



unicast alias 


Defines an name on the appliance for a streaming URL. When a client requests the 
alias content on the appliance, the appliance uses the URL specified in the unicast- 
alias command to request the content from the origin streaming server. 


universal time coordinates 
(UTC) 


An SG appliance must know the current UTC time. By default, the appliance 
attempts to connect to a Network Time Protocol (NTP) server to acquire the UTC 
time. If the SG appliance cannot access any NTP servers, you must manually set the 
UTC time. 


URL filtering 


See content filtering. 


URL rewrite rules 


Rewrite the URLs of client requests to acquire the streaming content using the new 
URL. For example, when a client tries to access content on www.mycompany.com, 
the appliance is actually receiving the content from the server on 10.253.123.123. The 
client is unaware that mycompany.com is not serving the content; however, the 
appliance access logs indicate the actual server that provides the content. 



W 



WCCP 


Web Cache Communication Protocol. Allows you to establish redirection of the 
traffic that flows through routers. 


Web FTP 


Web FTP is used when a client connects in explicit mode using HTTP and accesses an 
ftp:/ / URL. The SG appliance translates the HTTP request into an FTP request for the 
OCS (if the content is not already cached), and then translates the FTP response with 
the file contents into an HTTP response for the client. 


Websense log type 


A Blue Coat proprietary log type that is compatible with the Websense reporter tool. 



X 



XML responder 


HTTP XML service that rims on an external server. 


XML requestor 


XML realm. 
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After ICP, forwarding, and the SOCKS gateways are configured, use policy to create 
and manage forwarding rules. Forwarding, ICP, and SOCKS gateway rules should go 
in the <Forward> layer of the Forwarding Policy file or the VPM Policy file (if you use 
the VPM). 

The separate <Forward> layer is provided because the URL can undergo URL rewrites 
before the request is fetched. This rewritten URL is accessed as a server _ur l and 
decisions about upstream connections are based on the rewritten URL, requiring a 
separate layer. All policy commands allowed in the <Forward> layer are described 
below. 



Table B-1 . Policy Commands Allowed in the <Forward> Layer 



Forwarding 


Description 


Conditions 


client address= 


Tests the IP address of the client. Can also be used in 

<Exception> and <Proxy> layers. 


client . host= 


Tests the hostname of the client (obtained through RDNS). Can 
also be used in <Admin>, <Proxy>, and <Exception> layers. 


client . host . has name= 


Tests the status of the RDNS performed to determine 
client . host. Can also be used in <Admin>, <Proxy>, and 
<Exception> layers. 


client ,protocol= 


Tests true if the client transport protocol matches the 
specification. Can also be used in <Exception> and <Proxy> 
layers. 


date [ . utc] = 


Tests true if the current time is within the startdate..enddate 
range, inclusive. Can be used in all layers. 


day= 


Tests if the day of the month is in the specified range or an exact 
match. Can be used in all layers. 


has client= 


has client= is used to test whether or not the current 
transaction has a client. This can be used to guard triggers that 
depend on client identity. 


hour [ . utc] = 


Tests if the time of day is in the specified range or an exact match. 
Can be used in all layers. 


im. client= 


Tests the type of IM client in use. Can also be used in <Proxy>, 
<Exception>, and <Cache> layers. 


im. message . reflected= 


Tests whether IM reflection occurred. Can also be used in 

<Proxy> and <Cache> layers. 


minute [ . utc] =month [ . utc] = 


Tests if the minute of the hour is in the specified range or an exact 
match. Can be used in all layers. 
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Table B-1. Policy Commands Allowed in the <Forward> Layer (Continued) 



Forwarding 


Description 


proxy. address= 


Tests the IP address of the network interface card (NIC) on which 
the request arrives. Can also be used in <Admin> and <Proxy> 
layers. 


proxy. card= 


Tests the ordinal number of the network interface card (NIC) 
used by a request. Can also be used in <Admin> and <Proxy> 
layers. 


proxy. port= 


Tests if the IP port used by a request is within the specified range 
or an exact match. Can also be used in <Admin> and <Proxy> 
layers. 


server url [ . case sensitive | .no 
lookup] = 


Tests if a portion of the requested URL exactly matches the 
specified pattern. 


server url.address= 


Tests if the host IP address of the requested URL matches the 
specified IP address, IP subnet, or subnet definition. 


server url . domain [. case sensitive] 
[ . no lookup] = 


Tests if the requested URL, including the domain-suffix portion, 
matches the specified pattern. 


server url . extension [. case 
sensitive] = 


Tests if the filename extension at the end of the path matches the 
specified string. 


server url. host. has name= 


Tests whether the server URL has a resolved DNS hostname. 


server url . host [. exact | .substring! 
.prefix! .suffix! .regex] [.no lookup 
] = 


Tests if the host component of the requested URL matches the IP 
address or domain name. 


server url. host. is numeric= 


This is true if the URL host was specified as an IP address. 


server url.host.no name= 


This is true if no domain name can be found for the URL host. 


server url . host . regex= 


Tests if the specified regular expression matches a substring of 
the domain name component of the requested URL. 


server url. is absolute= 


Tests whether the server URL is expressed in absolute form. 


server url . path [. exact | .substring! 
.prefix! .suffix! .regex] 

[.case sensitive]= 


Tests if a prefix of the complete path component of the requested 
URL, as well as any query component, matches the specified 
string. 


server url . path . regex= 


Tests if the regex matches a substring of the path component of 
the request URL. 


server url.port= 


Tests if the port number of the requested URL is within the 
specified range or an exact match. 


server url . query . regex= 


Tests if the regex matches a substring of the query string 
component of the request URL. 


server url.regex= 


Tests if the requested URL matches the specified pattern. 


server url.scheme= 


Tests if the scheme of the requested URL matches the specified 
string. 


socks= 


This condition is true whenever the session for the current 
transaction involves SOCKS to the client. 
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Table B-1. Policy Commands Allowed in the <Forward> Layer (Continued) 



Forwarding 


Description 


socks . version= 


Switches between SOCKS 4/4a and 5. Can also be used in 

<Exception> and <Proxy> layers. 


streaming. client= 


yes | no. Tests the user agent of a Windows, Real Media, or 
QuickTime player. 


time [ . utc] = 


Tests if the time of day is in the specified range or an exact match. 
Can be used in all layers. 


tunneled= 


yes | no. Tests TCP tunneled requests, HTTP CONNECT 
requests, and unaccelerated SOCKS requests 


weekday [ . utc] = 


Tests if the day of the week is in the specified range or an exact 
match. Can be used in all layers. 


year [ . utc] = 


Tests if the year is in the specified range or an exact match. Can 
be used in all layers. 


Properties 


access server () 


Determines whether the client can receive streaming content 
directly from the OCS. Set to no to serve only cached content. 


ftp . transport ( ) 


Determines the upstream transport mechanism. 

This setting is not definitive. It depends on the capabilities of the 
selected forwarding host. 


forward ( ) 


Determines forwarding behavior. 

There is a box-wide configuration setting 
(conf ig>f orwarding>f ailure-mode) for the forward 
failure mode. The optional specific settings can be used to 
override the default. 


forward. fail open ( ) 


Controls whether the SG appliance terminates or continues to 
process the request if the specified forwarding host or any 
designated backup or default cannot be contacted. 


http . ref resh . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the upstream 
host when performing refreshes. Can also be used in <Cache> 
layers. 


http. server . connect attempts () 


Sets the number of attempts to connect performed per-address 
when connecting to the upstream host. 


http . server . recv . timeout ( ) 


Sets the socket timeout for receiving bytes from the upstream 
host. Can also be used in <Proxy> layers. 


icp () 


Determines when to consult ICP. The default is yes if ICP hosts 
are configured and if no forwarding host or SOCKS gateway is 
identified as an upstream target. 


im. transport ( ) 


Sets the type of upstream connection to make for IM traffic. 


integrate new hosts () 


Determines whether to add new host addresses to health checks 
and load balancing. The default is no. If it is set to yes, any new 
host addresses encountered during DNS resolution of 
forwarding hosts are added to health checks and load balancing. 
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Table B-1. Policy Commands Allowed in the <Forward> Layer (Continued) 



Forwarding 


Description 


reflect ip ( ) 


Determines how the client IP address is presented to the origin 
server for explicitly proxied requests. Can also be used in 
<Proxy> layers. 


socks gateway () 


The socks gateway () property determines the gateway and 
the behavior of the request if the gateway cannot be contacted. 

There is a box-wide configuration setting for the SOCKS failure 
mode. The optional specific settings can be used to override the 
default. 


socks gateway. fail open ( ) 


Controls whether the SG appliance terminates or continues to 
process the request if the specified SOCKS gateway or any 
designated backup or default cannot be contacted. 


streaming . transport ( ) 


Determines the upstream transport mechanism. This setting is 
not definitive. The ability to use streaming . transport ( ) 
depends on the capabilities of the selected forwarding host. 


trace . request ( ) 


Determines whether detailed trace output is generated for the 
current request. The default value is no, which produces no 
output 


trace . rules ( ) 


Determines whether trace output is generated that shows each 
policy rule that fired. The default value of no suppresses output. 


trace . destination ( ) 


Used to change the default path to the trace output file. By 
default, policy evaluation trace output is written to an object in 
the cache accessible using a console URL of the following form: 

http://SG ip address: 8081/Policy/ 

Trace/path 


Actions 


notify email ( ) 


Sends an e-mail notification to the list of recipients specified in 
the Event Log mail configuration. Can be used in all layers. 


notify snmp ( ) 


The SNMP trap is sent when the transaction terminates. Can be 
used in all layers. 


log message 


Writes the specified string to the event log. 


Definitions 


define server url. domain condition 
name 


Binds a user-defined label to a set of domain suffix patterns for 
use in a condition= expression. 
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This appendix discusses how to configure an SG appliance to participate in a Web Cache 
Communication Protocol (WCCP) scheme, when a WCCP-capable router collaborates 
with a set of WCCP-configured appliances to service requests. If you are already 
familiar with WCCP version 2 and want to get your router and SG appliance up and 
running right away, see the "Quick Start" on page 269. 



Overview 

WCCP is a C i sco-d evel oped protocol that allows you to establish redirection of the 
traffic that flows through routers. 

WCCP Version 1 

In WCCP version 1, the WCCP-configured home router transparently redirects TCP 
port 80 packets to a maximum of 32 appliances. (An SG appliance is seen as a cache in 
WCCP protocol.) 

One of the caches participating in the WCCP service group is automatically elected to 
configure the home router's redirection tables. This way, caches can be transparently 
added and removed from the WCCP service group without requiring operator 
intervention. WCCP version 1 supports only a single service group. 

Each applicable client IP packet received by the home router is transparently redirected 
to a cache. An SG appliance from the group is selected to define the home router's 
redirection hash table for all caches. All caches periodically communicate with the 
home router to verify WCCP protocol synchronization and SG availability within the 
service group. In return, the home router responds to each cache with information as to 
which appliances are available in the service group. 




The following are WCCP version 1 caveats: 

□ The home router IP must be configured on all participating interfaces and must 
match the home router address configured on the SG appliance. 

□ The adapter connected to the SG appliance must be Ethernet or Fast Ethernet. 
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□ For Cisco routers using WCCP version 1, minimum IOS releases are 11.1(18)CA and 
11.2(13)P. Note that releases prior to IOS 12.0(3)T only support WCCP version 1. 
Ensure that you are using the correct IOS software for the router and that the SG 
configuration protocol version number and router protocol version number match. 

For more information on WCCP Version 1, refer to the Cisco Web site. The rest of this 
appendix discusses WCCP version 2 only. 

WCCP Version 2 

For Cisco routers using WCCP version 2, minimum IOS releases are 12.0(3)T and 12.0(4). 
Release 12.0(5) and later releases support WCCP versions 1 and 2. Ensure that you use the 
correct IOS software for the router and that you have a match between the SG 
configuration WCCP version number and router protocol version number. 

WCCP version 2 protocol offers the same capabilities as version 1, along with increased 
protocol security and multicast protocol broadcasts. Version 2 multicasting allows caches 
and routers to discover each other through a common multicast service group and 
matching passwords. In addition, up to 32 WCCP-capable routers can transparently 
redirect traffic to a set of up to 32 appliances. Version 2 WCCP-capable routers are capable 
of redirecting IP traffic to a set of appliances based on various fields within those packets. 

Version 2 allows routers and caches to participate in multiple, simultaneous service 
groups. Routers can transparently redirect IP packets based on their formats. For example, 
one service group could redirect HTTP traffic and another could redirect FTP traffic. 



Note: Blue Coat recommends that WCCP-compliant caches from different vendors be 
kept separate and that only one vendor's routers be used in a service group. 



One of the caches participating in the WCCP service group is automatically elected to 
configure the home router's redirection tables. This way, caches can be transparently 
added and removed from the WCCP service group without requiring operator 
intervention. WCCP version 2 supports multiple service groups. 

The figure below illustrates a WCCP version 2 implementation using multiple routers and 
Appliances. In this scenario, routers 1 through n and caches 1 through m participate in the 
same service group. As in version 1, an appliance from the group is selected to define the 
redirection hash table in all routers for all caches. All caches periodically communicate 
with all routers to verify WCCP protocol synchronization and appliance and router 
availability within the service group. In return, each router responds to caches with 
information as to what caches and discovered routers are available in the service group. 
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Figure C-2. A Version 2 Configuration Using Packet Redirection to Multiple Routers and Caches 



Quick Start 

Two tasks must be completed to get WCCP running: configuring the router and 
configuring the SG appliance. If you have a standard router and SG configuration, use the 
Quick Start below. Otherwise, begin with the instructions in the procedure "To do initial 
router configuration:", below, and "To create an SG appliance WCCP configuration file 
and enable WCCP:" on page 269. 

If you require a more complicated configuration, start with "Examples" on page 276. 

To do initial router configuration: 

1. From the router (config) mode, tell WCCP which service group you want use. The 
Web-cache service group redirects port 80 (HTTP) traffic only. 

Router (config) #ip weep web-cache 

2. Enter the (config-if) submode by telling WCCP which IP address to use. 

Router (config) # int interface 

where interface is the adapter interface with an IP address. The prompt changes to 
configuration interface submode. 

3. Enable packet redirection on an outbound (Internet facing) interface. 

Router (config-if ) # ip weep web-cache redirect out 

4. Prevent packets received on an adapter interface from being checked for redirection 
and allow the use of Blue Coat bypass lists. 

Router (config-if ) # ip weep redirect exclude in 

For more information on WCCP router configuration, see "Configuring a WCCP Version 2 
Service on the Router" on page 270. 

To create an SG appliance WCCP configuration file and enable WCCP: 

1. Create a WCCP configuration file through either the SG appliance's CLI inline 

commands or through a text editor. Make sure that the home router you enter here is 
the home router that was named in the router's configuration. If you do have a 
mismatch, you must correct it before continuing. See "Identifying a Home Router/ 
Router ID Mismatch" on page 281. 

For more information on creating a configuration file, see "Examples" on page 276. 
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If you used the inline commands, you have completed WCCP configuration for both 
the router and the SG appliance and you have enabled WCCP on the SG appliance. No 
further steps are needed. 

2. If you used a text editor, copy the file to an HTTP server accessible to the SG 
appliance. 

3. Enable WCCP and download the configuration file to the SG appliance. 

SGOS# (config) weep enable 

SGOS# (config) weep path http://205.66.255.10/files/wccp.txt 
SGOS# (config) load weep-settings 

For detailed information on creating and installing a WCCP configuration file for an SG 
appliance, see Chapter 17: "WCCP Settings" on page 239 

Configuring a WCCP Version 2 Service on the Router 

Configuring a router requires that you work with two different types of configuration 
commands: 

□ Creating a service group (which uses global settings). 

□ Configuring the Internet-Connected Interface (which uses interface settings). 

Define service group settings before defining adapter interface settings. 

Setting up a Service Group 

Services are of two types: 

□ Well known services (web-cache for port 80 — HTTP — redirection) 

□ The web-cache service group is supported by both Cisco and Blue Coat. 

□ Dynamic services (which can be used for other services, such as FTP, RTSP redirection, 
and reverse proxy). 

□ Dynamic service uses identifiers ranging from 0-99 to name the service group. 

WCCP global settings allow you to name the service group and then define the 
characteristics for that service group. Even if you use the pre-defined Web-cache service 
group, you should: 

□ configure a multicast group address 

□ create and identify a redirection access list and associate it with a service group 

□ create and identify a cache bypass list and associate it with a service group 

□ create password authentication for messages sent by the service group to the router 
Syntax for configuring a service group (global settings): 

ip weep {web-cache | service-number } [group-address group_address] 

[redirect-list access-list ] [group-list access-list] [password 
password ] 

where: 



web-cache 


Enables port 80 (HTTP) service. 


service -number 


The identification number of the cache service group being controlled by the router. Services 
are identified using a value from 0 to 99. The reverse-proxy service is indicated using the 
value 99, although any value can be used for reverse proxy. 
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group- address 
groupaddress 


(Optional) If no redirect list is defined (the default), all traffic is redirected. The group address 
option directs the router to use a specified multicast IP address to coalesce the "I See You" 
responses to the "Here I Am" messages that it has received on this address. The group- 
address argument requires a multicast address used by the router to determine which cache 
engine receives redirected messages. The response is sent to the group address, as well. If no 
group address is defined (the default), all "Here I Am" messages are responded to with a 
unicast reply. 


redirect-list 

access-list 


(Optional) Directs the router to use an access list to control traffic redirected to the defined 
service group. The access-list parameter specifies either a number from 1 to 99 identifying a 
predefined standard or extended access list number, or a name (up to 64 characters long) 
identifying an existing standard or extended access list. The access list itself specifies which 
traffic can be redirected. 


group-list 

access-list 


(Optional) If no group list is defined (the default), all caches might participate in the service 
group. 

The group-list option directs the router to use an access list to determine which caches are 
allowed to participate in the service group. The access-list parameter specifies either a 
number from 1 to 99 identifying a predefined standard or extended access list number or a 
name (up to 64 characters long) identifying an existing standard or extended access list. The 
access list itself specifies which caches are permitted to participate in the service group. 


password 

password 


(Optional) By default, password authentication is not configured and authentication is 
disabled. 

The password option increases authentication security to messages received from the service 
group specified by the service-number. Messages that do not pass authentication are 
discarded. The password can be up to eight characters long. 

If you specify a password in the router configuration, you must also configure the same 
password separately on each cache. 



Naming a Service Group and Enabling WCCP 

WCCP version 2 is enabled when you name a WCCP service group. (Version 1 requires a 
specific enable command.) The service group can already exist, such as web-cache, or it 
could be a new group, such as 36. 

To name a service group and enable WCCP: 

From the router (config) mode, enter the following command: 

Router# (config) ip weep web-cache 

-or- 

Router# (config) ip weep 36 

Configuring a Global Multicast Group Address 

Benefits of using a multicast address include reduced WCCP protocol traffic and the 
ability to easily add and remove caches and routers from a service group without having 
to reconfigure all service group members. Multicast addresses fall within the range of 
224.0.0.0 to 239.255.255.255. 

Use the following syntax to configure a global multicast group address for multicast cache 
discovery. 

ip weep {web-cache | service-number] [group-address group_address ] 



To configure a multicast address: 

From the router ( config) mode, name the group that uses the multicast address, provide 
the address, then tell the router which adapter interface is used: 
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Router (config) # ip weep 36 group-address 225.1.1.1 
Router (config) # interface ethernet 0 

Router (config-if) # end 

Creating a Redirection Access List and Associating it with a Service 
Group 

Redirection access lists can contain commands redirecting packets from one network or 
cache to another. The lists also can be used to determine which caches participate in which 
service groups. 

The two lists, although similar, have different purposes, and are applied to the router 
differently. The redirection lists are applied with the redirect-list option. The cache bypass 
lists are applied with the group-list argument. Both lists can be identified with either a 
name or a number. 

Use the following syntax to create a redirection access list. This is partial syntax for this 
command. Access lists are very complicated; refer to the Cisco Web site for complete 
syntax. 

access-list acl_ID [deny | permit] protocol { [ sourceaddr source_mask] 

I [local_addr local_mask ]} 

where: 



acl ID 


Names the access list you are creating. You can use either a name or number. 


deny 


Indicates that you do not want to allow a packet to traverse the Cisco router. By default, the 
router firewall denies all inbound or outbound packets unless you specifically permit access. 


permit 


Selects a packet to traverse the PIX firewall. By default, the router firewall denies all inbound 
or outbound packets unless you specifically permit access. 


protocol 


Identifies, by name or number, an IP protocol. This parameter can be one of the keywords 
iemp, ip, tep, or udp, or an integer in the range 1 to 254 representing an IP protocol number. 
To match any Internet protocol, including ICMP, TCP, and UDP, use the keyword ip. 


source addr 


Indicates the address of the network or host from which the packet is being sent. Use the 
keyword any as an abbreviation for an address of 0 . 0 . 0 . 0. 


source mask 


Specifies the netmask bits (mask) to be applied to source addr, if the source address is for a 
network mask. Use the keyword any as an abbreviation for a mask of 0 . 0 . 0 . 0. 


local addr 


Indicates the address of the network or host local to the PIX firewall. The local addr is the 
address after NAT has been performed. Use the keyword host, followed by address, as an 
abbreviation for a mask of 255 . 255 . 255 . 255. 


local mask 


Specifies the netmask bits (mask) to be applied to local addr, if the local address is a 
network mask. Use the keyword host followed by address as an abbreviation for a mask of 

255.255.255.255. 



To create a redirection access list or a cache bypass list: 

From the router (config) prompt, name an access list and assign rules to it. 

Router (config) # access-list 100 deny ip any host 126.10.10.10 

Router (config) # access-list 100 permit ip any any 

Router# 

□ The commands above gave the access list a name of 100. 

□ Denied packets from any protocol to be sent from any host on the 126. 10. 10. 10 
network. 
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□ Permitted packets from any protocol to be sent from any other network. 

To associate a redirection access list with a specific service group: 

1. Create a redirection access list. 

2. Associate the access list with a specified service group. 

ip weep {web-cache | service-number] [redirect-list access-list] 
Router (config) # interface ethernet 0/0 

Router (config-if) # ip weep web-cache redirect-list 100 

Router (config-if) # end 
Router# 

To associate a cache bypass access list with a specific service group: 

1. Create a redirection access list, using the syntax discussed above. 

2. Associate the access list with a specified service group. 

ip weep {web-cache | service-number] [group-list access-list] 

Router (config) # interface ethernet 0 

Router (config-if ) # ip weep web-cache group-list 120 

Router (config-if ) # end 
Router# 

Configuring the Internet-Connected Interface 

WCCP interface settings allow you to configure the Internet-connected adapter interface 
that redirects Web traffic to the content engine. 

Using the interface commands allows you to: 

□ Enable and prevent packet redirection 

□ Enable reception of multicast packets for service group member routers 

Syntax for configuring an Internet-connected adapter interface (interface settings): 

ip weep [{web-cache | service-number] redirect out | group-listen] | 
redirect exclude in 



where: 



web-cache 


Enables the Web cache service group. 


service -number 


The identification number of the cache service group being controlled by 
the router. Services are identified using a value from 0 to 99. The reverse- 
proxy service is indicated using the value 99. 


redirect out 


Enables packet redirection on an outbound (Internet facing) adapter 
interface. 


group-listen 


On a router that is a member of a service group, enables the reception of 
pre-defined IP multicast packets. 


redirect 
exclude in 


Prevents packets received on an adapter interface from being checked for 
redirection. If the cache service-group is located on a separate router 
interface, the possibility exists that bypass filters could be enabled on the 
cache. 
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Using Packet Redirection 

WCCP communication among the routers and the appliances can be done by either 
directly addressing protocol packets to each router's and cache's IP address (as illustrated 
in Figure C-l on page 267) or by sending these packets to a common multicast address as 
illustrated in Figure C-3, below: 




Figure C-3. A Version 2 Configuration Using Multicast Packet Redirection 
You can configure redirection on inbound or outbound interfaces. 



To configure redirection on the outbound interfaces: 

Use the following syntax to configure redirection on the outbound adapter interface. 

ip weep {web-cache | service-number } redirect out 
From the router (config) prompt, enter the following: 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 

To exclude packet redirection on an inbound adapter interface: 

Use the following command to prevent packets received on an adapter interface from 
being checked for redirection. 

ip weep redirect exclude in 

The following example shows how to exclude Blue Coat adapter interface (xx, in this 
case) and allow use of Blue Coat bypass lists: 

From the router (config) prompt, enter the following: 

Router ( config) # int xx 

Router (config-if ) # ip weep redirect exclude in 

Router (config-if ) # end 

Enabling Reception of Multicast Packets 

Benefits of using a multicast address include reduced WCCP protocol traffic and the 
ability to easily add and remove caches and routers from a service group without having 
to reconfigure all service group members. You (optionally) set up a multicast group 
address in "Configuring a Global Multicast Group Address". In the following procedure, 
you enable the reception of the pre-defined IP multicast packets to routers that are 
members of the group. 
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Multicast addresses fall within the range 224.0.0.0 to 239.255.255.255. 

Use the following syntax to configure for multicast discovery of the cache(s). 

ip weep {web-cache | service-number } group-listen 

The following example configures the router to use the WCCP 36 service group to redirect 
port 80 destination traffic. WCCP protocol traffic uses multicast address 225.1.1.1. 
Adapter interface "Ethernet 0" is used to receive the multicast WCCP traffic. 

Router (config) # ip weep 36 group-address 225.1.1.1 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache group-listen 

Router (config-if) # end 

Saving and Viewing Changes 

Once you have made all the changes, you must permanently save them to disk. If not, the 
changes are lost at the next reboot of the router. 

To save router configuration: 

Router# write memory 

To display all current WCCP configuration settings: 

Use the following syntax to verify the settings in the new router configuration and to 
ensure that the appropriate cache engines are visible to the router. 

show ip weep {web-cache | service-number} [view | detail] 

where 



view 


(Optional) Lists all members of the identified service group and whether they have 
been detected. 


detail 


(Optional) Displays IP and protocol version information about the router. Displays IP, 
protocol version, state, initial and assigned hash, hash allotment, redirected packet, 
and connection time information about the associated cache engine (SG appliance). 



For example: 

Router# show ip weep web-cache view 

Global WCCP Information: 

Service Name: web-cache: 

Number of Cache Engines:! 

Number of Routers :1 

Total Packets Redirected: 186 

Redirect Access-list : 120 

Total Packets Denied Redirect: 57 

Total Packets Unassigned: -none- 

Group Access-list : 0 

Total Messaged Denied to Group: 0 

Total Authentication Failures :0 

WCCP Router Informed of: 
86.135.77.10 
186.135.77.20 

WCCP Cache Engines Visible: 
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186.135.77.11 

186.135.77.12 

WCCP Cache Engines Not Visible: 
-none- 



Examples 

This section provides detailed examples of both the router and SG configurations for: 

□ Standard HTTP redirection 

□ Standard HTTP redirection and a multicast address 

□ Standard HTTP redirection and a security password 

□ Standard transparent FTP 

□ A service group and alternate hashing 

For information and examples about using WCCP, refer to http://www.cisco.com/ 
univercd/cc/td/doc/product/software/iosl21/121cgcr/fun_r/frprt3/frd3005.htm. 

Displaying the Router’s Known Caches 

Use the router show command to display information about the appliances that are known 
to the router. 

Router# show ip weep web-caches 

WCCP Web-Cache information: 

IP Address : 192 . 168 . 51 . 102 
Protocol Version:0.3 
State :Usable 
Initial Hash 

Info : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
Assigned Hash: 

Info : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
Hash Allotment : 256 (100.00%) 

Packets Redirected: 0 
Connect Time : 00 : 00 : 31 
Router# exit 

Standard HTTP Redirection 

The web-cache service group enables HTTP traffic redirection on port 80. 

Router Configuration 

The following example enables standard HTTP traffic redirection on a WCCP version 2- 
capable Cisco router. 

Router (config) # ip weep web-cache 

Router (config) # interface ethernet 0/0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 
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SG Configuration 

To enable the Web-cache service group within the SG appliance, the following 
configuration file could be loaded. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

service-group web-cache 

# Specify the address for the router. 

home-router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 

end 

Standard HTTP Redirection and a Multicast Address 

Configuring a multicast address on a WCCP-capable router provides reduced WCCP 
protocol traffic and the ability to easily add and remove caches and routers from a service 
group without having to reconfigure all service group members. 

Router Configuration 

The following example enables the standard HTTP traffic redirection on a WCCP 
version 2-capable Cisco router. In this case, WCCP protocol traffic is directed to the 
multicast address 226.1.1.1. 

Router (config) # ip weep web-cache group-address 226 . 1 . 1.1 
Router (config) # interface ethernet 0/0 
Router (config-if) # ip weep web-cache group-listen 
Router (config-if) # ip weep web-cache redirect out 

Router (config-if ) # end 

SG Configuration 

To enable the standard Web-cache service group within the SG appliance, the following 
configuration file should be loaded. In this example, both network interfaces 0 and l 
participate within the service group. Both interfaces send and receive WCCP protocol 
packets by way of the multicast address. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

service-group web-cache 

# Specify the multicast address. 

home-router 239.192.5.3 

# Network interface 0 will participate. 

interface 0 

# Network interface 1 will also participate. 

interface 1 
end 

Standard HTTP Redirection Using a Security Password 

A simple eight-character password is configured within the router. This password must 
match the password configured within the SG appliance. 
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Router Configuration 

The following example enables standard HTTP traffic redirection on a WCCP version 2- 
capable Cisco router. 

Router (config) # ip weep web-cache password 29gy8c2 

Router (config) # interface ethernet 0 

Router (config-if) # ip weep web-cache redirect out 

Router (config-if) # end 

SG Configuration 

To enable the standard WCCP version 2 service group within the SG appliance, the 
following configuration file could be loaded. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified 

# here. 

service-group web-cache 

# Specify the address for the router. 

home-router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 
password 29gy8c2 
end 

Standard Transparent FTP 

In WCCP version 1, only HTTP traffic on port 80 could be redirected. In WCCP version 2, 
you can create a numbered service group that redirects other protocols on other ports. 

You set the service group on the router, and tell the SG appliance which ports should be 
redirected. 

Router Configuration 

In this configuration, you create a new service group that you are dedicating to FTP 
redirects. 

# Enables the service group that redirects ports besides 80. 

Router (config) # ip weep 10 

# Enables a service group that allows user-defined 

# ports to be redirected. 

Router (config) # int eO 

Router (config-if ) # ip weep 10 redirect out 

SG Configuration 

In this configuration, you take the service group created by the router and assign the 
characteristics to the group. 

SGOS# (config) inline weep eof 
weep enable 
service-group 10 
interface 0 
home-router 10 . 1 . 1.1 
protocol 6 
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priority 1 

service-flags ports-def ined 
service-f lags destination-port-hash 
ports 20 21 80 80 80 80 80 80 

eof 

Reverse Proxy Service Group 

This service group redirects IP packets for TCP destination port 80 traffic by hashing the 
source IP address. 

Router Configuration 

The following example enables the special SG service group on a WCCP-capable router. 

Router (config) # ip weep 99 

Router (config) # interface ethernet 0/0 

Router (config-if) # ip weep 99 redirect out 

Router (config-if) # end 

SG Configuration 

To configure the special SG service group on the appliance, a dynamic service group must 
be created as illustrated by the following example. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

# Service Group 99 is specially identified within the router 

# as representing the ProxySG Appliance service. 

service-group 99 

# Specify the address for the router. 

home-router 90.0.0.90 

# Network interface 0 will participate. 

interface 0 

# Specify the TCP protocol. 

protocol 6 

# The hash should be based on the source IP address. 

service-flags source-ip-hash 
end 

Service Group with Alternate Hashing 

You can create a special service group on a WCCP-capable router that uses alternate 
hashing when hot spots are detected. This service group redirects IP packets by hashing 
the source IP address. 

Router Configuration 

In this configuration, you create a new service group that you are dedicating to Website 
hot spots. 

Router (config) # ip weep 5 

Router (config) # interface ethernet 0/0 

Router (config-if ) # ip weep 5 redirect out 

Router (config-if ) # end 
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SG Configuration 

To configure this special service group on the SG appliance, a dynamic service group must 
be created. 

# Enable WCCP to allow WCCP protocol communication between 

# the ProxySG Appliance and the home router. 

weep enable 

# By default, the WCCP version 2 protocol is assumed. An 

# explicit "weep version 2" command could be specified here. 

# Service Group 5 is created to redirect standard HTTP 

# traffic and use an alternate hash function based on the 

# source IP address, if necessary, 
service-group 5 

# Specify the address for router 1. 

home-router 90.0.0.90 

# Specify the address for router 2. 

home-router 90.0.1.5 

# Network interface 0 will participate. 

interface 0 

# Specify the TCP protocol. 

protocol 6 

# The following two flags specify that a hash function based 

# on the destination IP address should be applied first. If 

# a hot-spot is detected, then an alternate hash 

# function using the source IP address should be used, 
service -flags destination-ip-hash 

service -flags source -ip- alternate -hash 
end 

Troubleshooting: Home Router 

If you install WCCP settings and then later upgrade the Cisco IOS software or change 
network configuration by adding a device with a higher IP address, the change might 
result in a different home router IP assignment. WCCP might or might not work under 
these conditions, and performance might decrease. If you upgrade the router software or 
change the network configuration, verify that the actual home router IP address and home 
router IP address in the WCCP configuration match. 

To verify the home router IP address matches the home router IP address listed in 
the WCCP configuration: 

1. From the router CLI, view the WCCP configuration: 

Router# (config) show ip weep 

The home router information appears, similar to the example below: 

Global WCCP information: 

Router information: 

Home router Identifier : 1 95 . 200 . 10 . 230 
Protocol Version: 2.0 

2. From the Blue Coat SG appliance, verify that the home router IP address specified in 
the SG WCCP configuration file is the same as the actual home router IP address 
discovered through the router CLI command. The following is an SG WCCP 
configuration file showing the same home router IP as in the example above: 
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SGOS# show weep config 

;WCCP Settings 
;Version 1.3 
weep enable 
weep version 2 
service-group web-cache 
interface 1 

home-router 195.200.10.230 
end 

In this case, the two home router identifiers match. 

Identifying a Home Router/Router ID Mismatch 

The following is some helpful information for resolving a home-router /Router ID mis- 
match that results in the router crashing the SG appliance. This situation can occur when 
the router interface is set to a higher IP address than the home-router and WCCP 
messages show w/bad rev id. 

WCCP version 1 does not care what home router the cache had configured. So if you 
upgrade from WCCP version 1 to WCCP version 2, the router might pick a different IP 
address than was configured as a home router in the cache. 

This means that a mismatch can occur after an upgrade. 

SG Configuration 

Use the show weep statistics command to identify the configured home router and the 
highest router IP. 

SGOS# (config) show weep statistics 



Service Group ident. 


: 512, 1, 9, 


1,6,18, 




1755,554,20,21,80,80, 


80, 80 






Home Routers 


: 10. 2. 3. 224 «- 


Configured Home Router 


Hotspots announced 


: 0 






Assignment state 


: idle 






Designated Cache 


: 10. 2. 3. 228 «- 


Blue Coat IP 




Announcement key # 


: 2 






Cache view change # 


: 13 «==== 


# times cache view 


changed 


Router View Changed 


: 0 






Recent hit count 


: 0 






Primary hit count 


: 0 






Alternate hit count 


: 0 






Instance IP address 


: 10 . 2 . 3 . 228 


« Blue Coat 


IP 


Sequence info 


: 1 0 . 2 . 3 . 


231, 636 




Query response info 








Active 


: 1 






Primary hash weight 


: 0 






Hotspot information 


: 0, 0, 0, 0 






Total assign weight 


: 0 






Router IP address 


: 10. 2. 3. 231 «— 


Router ID/Highest IP on 


Router 








Receive # 




: 636 




Change # 




: 4 




Activation time 




:Wed, Jan 30 2002 


00:17:58 


Last I-See-You time 




:Wed, Jan 30 2002 


01:08:58 
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Active caches 
Assignment key 
Router state 
Cache 
Active 



: 10 . 2 . 3 . 228 
:10.2.3.228,2 
: active 

: 10 . 2 . 3 . 228, L, D 

: 1 



Notice that .231 is highest IP on router and is automatically selected as the home router, 
even though .224 is the configured home router IP. 

You can also use the show weep configuration command if you already know the 
highest IP and just want to know what the SG appliance identifies as the home-router. 

SGOS# (config) show weep configuration 

;WCCP Settings 
/Version 1 . 3 
weep enable 
weep version 2 
service-group 9 
interface 0 

home-router 10.2.3.224 

protocol 6 
priority 1 

service-flags ports-defined 
service- flags destination- ip-hash 
ports 1755 554 20 21 80 80 80 80 



Router Configuration 

The configuration below reveals that two interfaces are active on the router, and that one 
of the IP addresses is higher than the home router configured in the SG configuration file. 
The higher IP address takes over duties as the home router, causing a mismatch between 
the router and the SG appliance. 

Router# show conf 

Using 689 out of 129016 bytes 

version 12.1 

service timestamps debug uptime 
service timestamps log uptime 
no service password-encryption 
hostname NachoL3 

enable secret 5 $l$r6nJ$dr58AZ . ZDg6RKA6MYeGRb. 
enable password nacho 

ip subnet-zero 
no ip routing 
ip weep 9 

interface FastEthernetO/ 0 

ip address 10.2.3.224 255.255.255.0 

ip weep 9 redirect out 
no ip route-cache 
no ip mroute-cache 
speed 100 
half-duplex 

i 

interface FastEthernetO/ 1 

ip address 10.2.3.231 255.255.255.0 

no ip route-cache 
no ip mroute-cache 
speed 100 
half-duplex 
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Correcting a Home Router Mismatch 

The home router must have the same IP address on both the router and the SG appliance. 
Every time a higher IP address is introduced to the router, the higher address becomes the 
home router. 

On a WCCP router, the Router Identifier parameter is dynamically assigned. It cannot 
be manually configured. 

To set the correct home router IP address on the SG appliance: 

You cannot edit a WCCP configuration file created by the SGOS inline commands. You 
must recreate the configuration file. For more information on creating a WCCP 
configuration file using CLI commands on an SG appliance, see "Creating a Configuration 
File using CLI Inline Commands" on page 247. 

If you created a text file and downloaded it, you can edit the file and then download it 
again to the SG appliance. For more information for editing the WCCP text file and 
downloading it, see "Creating a Configuration File using a Text File" on page 247. 
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connections, securing 34 
device security, setting 32 
devices, authorizing 36 
explicit deployment 
configuring 26 

destination port, preserving 28 
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optimizing 16 
securing 32 
overview 13 

policy gestures available for use with 50 
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security settings, configuring 32 
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configuring 23 
load balancing 24 
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optimization, understanding 42 
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attack-detection 
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connection-limit, explained 55 
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failure-limit, explained 55 
global defaults 53 
global defaults, changing 54 
unblock-time, explained 56 
warning-limit, explained 56 
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mode, entering 53 
overview 53 
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add or remove server from group 57 
configuration, viewing 58 
configuring 57 
creating 57 
editing 57 

hostname, explained 57 
request-limit, explained 58 
authentication, device. See device authentication. 88 



bandwidth management 
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allocation examples 78 
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enabling or disabling 72 
flow classification 71 
maximum bandwidth 69 
minimum bandwidth 68 
overview 67 
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Blue Coat SG 

alternate hashing example 280 
configuration file 247 
configuration file, creating 244 
configuration file, creating with text editor 247 
configuration file, loading 248 
configuration file, quick start 241, 269 
configuration file, syntax 244 
FTP example 278 

home router IP address, verifying 280 
HTTP configuration example 277 
HTTP redirection multicast address example 277 
HTTP redirection with password example 278 
load balancing 243 
optional negation syntax, using 244 
reverse proxy example 279 
simultaneous connections to, viewing 56 
WCCP versions supported 239 
WCCP-known caches, displaying 276 
bluecoat profile, understanding 88 
BWM, see bandwidth management 
byte-cache dictionary, manually resizing 45 

c 

cache bypass list 

associating with service group 273 
creating 272 
.car file, SG Client 153 

CLI configuration file, creating for SG appliance 247 
Client Manager 
changing 175 
setting 151 
SG Client 140 
combined deployment 
configuring for ADN 31 
configuration file 

creating with inline commands 247 
creating with text editor 247 
loading on SG appliance 248 
connections, securing for ADN 34 
CPL 

enabling ICP 126 
RADIUS policies, creating 136 

D 

D range multicast address, explained 98 
Data Collector, SG Client 176 



default sequence 

deleting hosts or groups 120 
device authentication 

appliance certificates, about 88 
cipher suites, changing 94 
cipher suites, default 89 
CLI syntax 95 
device ID, setting 94 
overview 88 
platforms supported 90 
profile, creating 93 
profile, understanding 88 
device security 

ADN, setting for 32 
devices 

ADN authorization 36 
Diagnostics & Configuration, SG Client 178 
directives 

forwarding, available 114 
forwarding, using 114 
SOCKS gateways, available 192 
DNS 

forwarding, used in 201 
health checks, used in 201 
SOCKS gateways, used in 201 
document 

conventions 12 
Do-Not-Fragment, see PMTU 

DRTR service configuration, deleting hosts or groups 
120 

E 

event log 

notifications, health checks 208 
state changes 208 
explicit deployment 

ADN server subnets, managing. 26 
ADN, configuring for 26 
load balancing for ADN network 28 
external services 

health checks tests 205 

F 

failover 

configuring, overview 98 
group secret 99 
master, explained 97 
multicast address, using 98 
priority ranges 99 
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statistics page, viewing 99 
VRRP, using with 97 
failover group 

configuring as session monitor 134 
forwarding 

CLI, configuring through 111 
configuring 106 

default sequence, configuring 111 
default sequence, understanding 110 
directives 

available 114 
host 

fail open/closed 116, 194 
installable list 

creating 119 

host timeout values 116, 194 
using 114 

DNS resolution, using 201 
global defaults 
configuring 109 

load balancing and host affinity, configuring 
109 

group 

health checks tests, editing 216 
groups 

configuring 107 

load balancing and host affinity, configuring 
108 

health checks 214 
host 

configuring 106 

load balancing and host affinity, configuring 
107 

TCP health check 214 
hosts 

fail open/closed 116, 194 
load balancing 

understanding 103 

load balancing and host affinity, using together 
104 

policy commands in forward layer 263 
policy, managing with 263 
statistics, locating 113 
understanding 103 
FTP 

router configuration for 278 
SG appliance, configuration for 278 
WCCP example 278 



Group Policy Object (GPO) distribution, SG Client 
168 

H 

hash table, see redirection hash table 
health checks 
about 203 
categories 200 
CLI 230 
composite 
about 221 

composite and group tests 222 

copying 226 

default settings 207 

default settings, changing 208 

deleting 226 

disable 207 

DNS resolution 201 

DRTR rating service, defaults 207 

enable 207 

external services tests 205 
forwarding 214 
group tests 206 
HTTP/HTTPS tests 205 
ICMP test 204 
intervals, setting 207 
messages, status 227 
naming conventions 203 
notifications 208 

explicit, configuring 212 
global, configuring 211 
notifications, configuring 211 
overview 200 
policy, understanding 229 
policy, using 200 
SNMP traps 208 
SOCKS gateways 214 
SSL test 204 
state, viewing 227 
TCP socket test 204 
tests 203 

thresholds, setting 207 
types 

user-defined composite 203 
user-defined host 203 
user-defined 
about 221 

composite checks, creating 223 
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host checks, creating 223 
user-defined, composite, about 222 
home router 

mismatch errors 281 
SG IP address 280 
troubleshooting 280 
version 1 usage 267 
version 2 configuration 240, 268 
WCCP IP address 280 
host affinity 
forwarding 

global defaults, configuring 109 
group, configuring 108 
host, configuring 107 
load balancing, using with 104 
SOCKS gateways 
configuring 185 
groups, configuring 186 
setting global defaults 188 
hot spot, working with 243 
HTTP 

health checks test 205 

user-defined health check tests, using with 221 
HTTP redirection 

multicast address example 277 
multicast address router configuration 277 
password example 277 
router configuration example 276 
router configuration for password 278 
SG configuration 277 
SG multicast address configuration 277 
SG password example 278 
HTTPS 

health checks test 205 

user-defined health check tests, using with 221 

I 

ICMP 

health check test 204 

user-defined health check tests, using with 221 
ICMP broadcast echo 
configuring 234 
ICMP error message 

ICMP host unreachable 235 
ICMP timestamp echo 
configuring 234 
ICP 

creating an installable list for 121 
enabling through CPL 126 



hierarchy 121 

icp_access_domain directive 123 
icp_access_ip directive 124 
installable list, creating through Management 
Console 125 
restricting access 123 
installable list 
ICP 121 

SOCKS gateways 192 
integrated host, timeout interval 116, 194 
intervals, health checks, setting for 207 

L 

load balancing 

assigning percentages 243 
forwarding 

global defaults, configuring 109 
group, configuring 108 
host, configuring 107 
host affinity, using with 104 
SOCKS gateways 
configuring 185 
groups, configuring 186 
setting global defaults 188 
understanding 103, 242 

M 

multicast 

D range address, explained 98 
failover, using with 98 
multicast address 
configuring 271 
router configuration 277 
SG configuration 277 
syntax 271 

multicast packet reception, enabling 274 

N 

notifications 
default 208 
e-mail 208 
event logging 208 
snmp 208 

o 

optional negation syntax, using 244 

P 

packet redirection 
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with RIP 131 
PMTU 

enabled by default 235 
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proxies 
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Q 

quick start 
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R 
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RADIUS session monitor 
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configuring 135 
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using passwords with 131 
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s 

See also Blue Coat Web Filter 
SG Client 
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group 
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T 

TCP 
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about 59 

CLI commands 65 
configuring 63 
deployment 63 
TCP NewReno 
configuring 234 
TCP/IP 

configuration, showing 236 
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ICMP timestamp echo 234 
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w 

WCCP 
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alternate hashing example 279 
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global settings, syntax 270 

global settings, using 270 

home router mismatch, troubleshooting 283 

home router troubleshooting 280 

hot spot, working with 243 

HTTP redirection example 276 

interface commands, syntax 273 

interface commands, using 273 
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load balancing, understanding 242 

multicast address, configuring 271 

multicast packet reception, enabling 274 

optional negation syntax, explained 244 

overview 239, 267 

packet redirection, enabling 274 
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quick start 269 

router configuration, initial 240, 269 
saving changes 275 
service group, naming 271 
service group, setting up 270 
settings 239 

settings, understanding 239 
transparent redirection, using with 239 
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version 2 overview 239, 268 
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Web Cache Control Protocol, see WCCP 



291 



Volume 5: Advanced Networking 



292 



